Show durable reservation acquisition progress in download tasks

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

@@ -299,3 +299,15 @@ Read: memory-index, project-positioning, current-state latest September sections
 - Actual local UI: reloaded only the independent verification tab, then selected9/17 fields→history9/16 prices→same cached9/17 fields→9/15 fields→9/16 prices. At each step the date/type matched and only one review body was visible.9/15 retains its1 missing-room item,9/16 retains its one blank price key0/1,9/17 retains0 active field items; no save, cancellation or generation was triggered. All3 complete review objects match the pre-layout authenticated baseline exactly. Private before/after JSON evidence and screenshots are in `production-validation-20261007/unified-manual-check-{before,after}-20261008.json` and `unified-manual-check-layout-20261008.png`; raw material stays outside Git.
 - Responsive result: observed CSS widths375/767/1024/1440 verified. Initial767 check found7px page overflow from the absolute screen-reader label inside the price table; setting the new parent to position:relative bounds that label, and final375/767 checks now have scrollWidth equal clientWidth. Wide tables retain their existing contained scrolling. Temporary viewport overrides were reset. The preserved visual palette/typography was preferred over the design search's unrelated liquid-glass/marketing recommendations. Existing user tabs were not reloaded; result tab retained. Static changes are served by the running8875 instance, without a service restart, new acquisition, hotel write, real review mutation, report generation or remote push.
 - Promotion candidate: integration-owned product/data-flow docs should describe independent “需处理日期” navigation followed by a single “人工核对” workspace, keeping source completeness and price decisions as distinct business stages. No conflict with ADR006/007 or additional business-policy confirmation. Remaining action for users is refreshing an existing page to load the new layout, then continuing original pending tasks.
+
+## Same-task Follow-up: Acquisition Progress Display
+
+- User requests a progress bar, acquisition counts and fetching/completed status. Concurrent Task Gate Passed for same task/feature/codex/owned checkout/branch/base, no peers and clean initial checkout. Project Context Loaded: retained required memory/positioning/decisions004/006/007/architecture/domain/evidence/reflection/commitments/stale context, refreshed task record and planning entry/gate. Goal: truthful reservation-level acquisition visibility without changing completion, source-field or price rules. Modules: OHIP source progress, executor/queue public snapshots, static download UI and focused tests. Constraints: preserve immutable capture/checkpoints, user decisions and completed reports; no new Oracle acquisition for testing and no fabricated progress/time estimates. Existing design skill/system applies to the same download-card layout. Planning Gate Passed.
+- Plan: persist privacy-minimized progress outside immutable capture inventories as records complete; expose it in existing task GET snapshots. Show completed/total reservations and a determinate bar once the initial search establishes the total, with an indeterminate state before that. Keep below100% until final completeness/recheck succeeds, distinguish failed/interrupted collection, and label successful acquisition “已完成” even when subsequent human checking is still pending. Recover counts from previously completed local capture metadata where validated, without refetching. Implement collection/API and UI in parallel, verify synthetic in-progress/failure/retry/restart/completion states, safely activate the local service after checking for active jobs, and confirm the actual existing completed acquisitions in the page.
+
+- Backend outcome: reservation-level observations now persist in a private request-level `progress.json`, outside immutable attempt inventories. The existing task snapshots expose only phase/completed/total/percent/updated_at through source/executor/authorized wrapper/queue; reading progress requires no OHIP access refresh, HTTP, execution lock or guest payload read. Initial search establishes total, completed increments after each complete record, and final source recheck/checkpoint publication gates100%. Acquisition failure stays below100%; retry resets the observation, restart exposes interruption, and later report failure does not erase proven acquisition completion. Completed legacy sources recover counts from bounded validated request/ready/result/capture metadata. Source/version/hash/processor identity, shared business rules and original payload remain unchanged; observation write failure cannot fail acquisition.
+- Frontend outcome: the download card now shows a compact progress bar, count and “取数中／已完成” status, with three-language copy and accessible progress values. Unknown totals show an indeterminate indicator; completeness verification displays at most99%. Completed acquisition remains separate from manual field/price review and overall report status. Failed/interrupted collection is explicit, unrelated selected dates hide the old task's progress, and legacy completion without counts does not invent a total. Existing dates/manual workspace and all decisions remain.
+- Verification:118 backend cases passed with `runtime/bin/python -m unittest tests.test_arr_acquisition_progress tests.test_arr_web_downloads tests.test_ohip_arr_data tests.test_arr_data_review.DirectFieldReviewTests tests.test_arr_download_runtime`;84 JavaScript cases passed with `node --test tests/javascript/*.cjs`;13 static UI cases passed with `runtime/bin/python -m unittest tests.test_arr_web_daily_price_review_ui tests.test_arr_web_daily_visual_ui`. Focused tests cover true row counts rather than request counts, final recheck/checkpoint failure at6/6 still99%, optional field gaps with acquisition completed, observation writer failure isolation, unlocked/no-HTTP getters, read-only legacy metadata, corrupt/context-mismatched observations, queued/retry/restart/later-report-failure precedence, API/wrapper forwarding and date/context UI recovery. A preliminary read-only queue inspection used the wrong table name and was corrected to `downloads`; it did not mutate storage and is not counted as a test failure or successful verification.
+- Actual UI verification: a temporary loopback-only synthetic fixture verified unknown total →58/85 at68% →85/85 verification at99% →100% while report processing continues →failed68%, without Oracle, real database or report mutations. Fixture/tab were stopped and closed. Before activation the real queue had no active tasks. Gracefully restarted the same8875 LaunchAgent once; all required processing/acquisition/monthly/download health checks are ready. In a new independent tab,9/15 now shows85/85,100%,取数状态已完成, while its original room item remains0/1 and generation disabled.9/17 API reports106/106 completed. The replayed9/16 request lacks an original source folder, so it truthfully shows completed with historical counts unavailable rather than borrowing counts from another request.375px CSS-width check confirms scrollWidth=clientWidth and visible counts; temporary viewport override reset. User tabs were not reloaded.
+- Preservation/evidence: exact authenticated before/after comparison confirms all3 complete manual-review objects, all15 original capture metadata hashes, and all6 queue statuses/job IDs/attempt counters unchanged. No new Oracle request, hotel write, price/source decision, finalization, report/monthly generation, schema/config/credential change, primary checkout edit or remote push occurred. Private evidence remains in `production-validation-20261007/acquisition-progress-{before,after}-20261008.json`, synthetic fixture source, and `acquisition-progress-local-20261008.png`; actual result tab retained. Node syntax, Git whitespace and project-document gates apply before commit.
+- Promotion candidate: integration-owned product/data-flow/current-state documentation should describe reservation-level acquisition progress as a distinct observed stage, with unknown totals before paging completes and100% only after completeness/checkpoint success. Acquisition completion does not establish report completion or remove manual review. No new business-policy decision or ADR conflict. Remaining limitation: some replayed historical requests have no own acquisition counts; current new acquisitions persist them. Existing unresolved local-status fetch timeout resilience and same-page price redraw draft behavior remain separate follow-ups, not claimed fixed here.