fix: recover stale sessions without masking ARR submission errors

.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md

@@ -199,3 +199,14 @@ Read: memory-index, project-positioning, current-state latest September sections
 - Local activation: backed up only the editing9/17 review, then used the existing internal append-only reanalysis operation with expected revision2. Authenticated API now reports editing revision3/pending0/total0/can_finalize=true,18 cancellations excluded, no job and no finalize intent. Original data SHA remains `b9e115470f3ce4d1a31fde03308c18f0854c9daef5a8beb71d8ca5b997cdc831`; original manifest SHA remains `8efb54d2737d15d837295ffa7f5e5bd1ff0d467d89fb1e956de6b1055a8c076f`.10/7 remains finalized source revision4 and its existing price-review job, unchanged. No Oracle call, service restart, policy-pin change, Finance write, real daily/monthly generation, remote push or primary-checkout edit.
 - UI verification: preserved the original10/7 price panel and opened a separate local result tab. The pending-date button was initially disabled after restoration; choosing9/17 refreshed its enabled state, then opening the existing pending task made no new download. Page visibly shows9/17,0/0 confirmed,18 excluded cancellations, “没有待完善字段”, and an enabled “确认并生成日报”. Did not click generation. Both result and existing price tabs are retained. Private screenshot: `/Users/chillishark/Library/Application Support/ARR2.0/production-validation-20261007/sept17-optional-review-cleared-20261008.png`.
 - Private audit: `production-validation-20261007/sept17-optional-reanalysis-dccb6cbb03c4/{receipt,activation}.json`; replay manifest `7e4ec018d8898864c4fabacc4e2fba8be8e917704b95bc4e6fc7467d8c635783`; optional-only projected data `8afddb5d08bbc0c8814c1036db6b0be91aa45cb25676bc25731e642b8581ad9f`; pre-append backup `ohip-production-57106-20261008/sept17-source-reanalysis-backup-20261008-123341`. Raw guest data stays outside Git. Promotion candidate: explain old pending captures require explicit source-policy interpretation rather than blanket staff confirmation; retain current optional/required distinction. Broader report-scope alignment remains deferred.
+
+## Same-task Follow-up: September16 Submission Recovery
+
+- User reports selecting9/16 and seeing “尚未查到任务，可继续提交原请求”. Concurrent gate Passed for resumed task/feature/codex/owned checkout/base2417b1a with no peers. Project Context Loaded: retained required memory/positioning/decisions/architecture/domain/evidence/reflection/commitments/stale context plus current task record and planning-gate instructions. Relevant boundaries: two input paths, original pricing/Finance identity, independent report dates, no duplicate source acquisition after an uncertain response. Primary unknown dirty docs remain untouched; September restrictions remain superseded only by explicit October authorization. Planning gate Passed.
+- Read-only evidence: current live queue has only9/15,10/7,9/17; user request88cf3094edc2e82dec679e27c4bd3e57 is absent. At20:53:21 local service log records POST /api/arr-downloads then GET for that ID. Existing logs intentionally retain path only and omit HTTP status/error bodies, so exact historical refusal cannot be reconstructed. Browser-control copies still show10/7 and9/17; the user-visible older tab connection times out. Do not assert a guessed historical failure, lack of9/16 Oracle data or an Oracle outage.
+- Confirmed code issue: submission catches400/409/503 but not403 for toast, then GET404 replaces any known submit rejection with generic not_received. A stale CSRF token after session/cookie changes can cause this precise path even while GET remains authenticated. It is a reproducible candidate, not proven historical cause.
+- Plan: retry a mutation once only after explicit403/SESSION_INVALID, refresh token from authenticated /api/session only for the same username, preserve exact body/path/intent, and retain a definite rejection reason when reconciliation finds no task. Never retry network/500/other403 automatically. Add focused synthetic regression checks and verify local UI without submitting a new Oracle read or changing saved price/source decisions.
+- Outcome: shared API refreshes a stale token once only after an explicit403/SESSION_INVALID. Authenticated /api/session must identify the same original username and supply a valid token; the retry preserves method/path/body/headers/returnEnvelope. A second rejection,401, changed username, malformed token, network loss,500 or any other403 does not trigger another mutation. Submission keeps a known4xx error reason when GET reconciliation returns404; generic not_received now clearly directs explicit retry. Existing uncertain-intent identity and independent-date behavior stay intact.
+- Verification:56 JavaScript submission/source-review cases passed (8 new focused recovery/boundary cases), including exact body/request-ID retention, one retry limit,401/user-change/invalid-token refusal, other403 refusal, price decision body/extra-header/envelope preservation,500 uncertainty and existing lost-response/404 replay. Both scripts passed node syntax checks and Git whitespace checks. Independent agent reproduced stale-token POST403→GET404 in the actual frontend sandbox and a pure-memory backend: no queue.create call; then reviewed the final retry boundaries with no blocking issues. This establishes the bug mechanism, not the unknown historical HTTP response for the user's submission.
+- Local verification: static changes are served immediately without restart. Reloaded the agent result tab only, selected9/16, and confirmed enabled “下载并处理” and “可下载所选日期的报表”;9/17 remains in the pending-date list and10/7 stays at0/2 price decisions. Did not press download, retry, finalize, or save prices; no new Oracle read/Finance write/task creation. The older user-visible tab's failed browser connection was not bypassed; user should refresh that page to receive the fix. Private screenshot `production-validation-20261007/sept16-submission-ready-20261008.png`; existing price tab and result tab retained.
+- Follow-up/promotion: exact9/16 historical rejection remains unknown because current path-only logs omit status. Explain this evidence limit rather than claim Oracle no-data or prove session rejection for that event. User can explicitly retry the original9/16 intent from the refreshed page; then assess authoritative queue progress. Canonical UI/API recovery documentation should record bounded same-user refresh and preserved definite-error details at integration. No remote push, production deployment, primary-checkout edit or report generation occurred.