fix: refresh public dashboard and BI telemetry

.project-docs/30-worklog/current-state.md

@@ -27,6 +27,24 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
   queued downstream message explicitly says Finance database commit is complete while the outbox waits for its
   consumer. Persisted `local-...` delivery keys and existing trace fields remain unchanged. Trace/Web tests (27) plus
   Python/JavaScript syntax and diff checks pass; no live task or business data was mutated.
+- Performed a read-only live diagnosis after a user reported that Daily Report uploaded but monthly did not update.
+  Daily run 39 is accepted and Finance version 14 is active with 111 retained rows for 2026-08-01; its
+  `arr.daily_version_committed` outbox event was initially pending with zero attempts. The dedicated worker was then
+  started in detached Screen, consumed the backlog through event 20, and published active August V01 (`更新至
+  2026-08-01`, 111 rows); July V05 (`更新至 2026-07-27`, 987 rows) also became active while older July V04 was
+  superseded. The registered XLSX/result pair exists and the Web health endpoint remains ready. The worker is running
+  for this session, but reboot-persistent supervision is still open; no re-upload or source-code change was made.
+- Performed a second read-only BI freshness diagnosis after August publication advanced. Active August V02 is now
+  `更新至 2026-08-02` with 268 rows, and a fresh repeatable-read analytics query returns the same watermark and
+  `updated_at=2026-08-03 14:21:29 +08`. An already-open BI page can still show 8.1 because `app.js` loads analytics
+  only at boot, first BI entry or month change; the monthly page's four-second poll does not refresh BI. This is a
+  frontend freshness bug, not a monthly worker/database publication failure. No code or business data changed.
+- Implemented BI freshness detection for desktop and public H5. While visible, each surface checks its lightweight
+  month metadata endpoint every five seconds and reloads full analytics only when the selected month's `updated_at`
+  changes or the selected month changes. Polling pauses while hidden, resumes with an immediate check, preserves the
+  last good snapshot during transient failures, and keeps the existing four-second monthly-history polling separate.
+  Static BI/Web tests pass 5/5 and 19/19; both JavaScript syntax checks and `git diff --check` pass. No API, report or
+  business data behavior changed.
 - Fixed company-report duplicate publication. A retry now validates the existing archive/result pair against the
   deterministic reservation and builder `semantic_sha256`, verifies the archive hash against the result JSON, and
   reuses the first successful artifact metadata instead of comparing the new XLSX binary SHA. Partial, corrupt or
@@ -42,6 +60,49 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
   auto-generate a report. Historical jobs without source metadata remain readable and show that the source was not
   recorded. Full discovery passes 360 tests with 10 optional skips; no live upload, activation, report generation or
   service restart was performed because the available browser session was unauthenticated.
+- A read-only live follow-up found accepted Booking Excel batch 7 active with 72 rows and no review draft. The latest
+  August `01-10` jobs contain `source: null` and all five company results fail at `publish` with
+  `COMPANY_REPORT_PUBLISH_FAILED` after building row counts. The port-8766 Web process predates both source-traceability
+  and current duplicate-publication handling, so a controlled Web restart followed by one authorized rerun is required;
+  no restart or backfill was performed.
+- Clarified company-report source and publication status copy for operators. The job panel now says `本次任务使用的
+  Excel`; missing metadata says `未记录，无法确认使用了哪份 Excel` and explains that the filename/batch were not saved.
+  `COMPANY_REPORT_PUBLISH_FAILED` now says the data reached publication but the official Excel was not saved, and
+  explicitly distinguishes that error from successful reuse of a complete identical version. Focused Web/company and
+  publisher tests plus JavaScript syntax checks pass. Existing `source: null` jobs remain untraceable and no live
+  restart, report rerun or business-data mutation was performed.
+- Removed the redundant Booking Excel provenance card from company-report job details and the provenance column from
+  generation history. The upload/review current-source panel and server-side job `source` metadata remain intact for
+  operation and audit. Web/company regression passes 29 tests, JavaScript syntax and runtime-reference checks pass,
+  and no report or business data changed.
+- After the operator-reported 8766 restart and another `2026-08/01-10` attempt, job
+  `253ce23dc7544d34a6e0fb9405ac4d9a` again built all five row sets (`54/18/7/1/15`) but failed at `publish`; the prior
+  `c5358fa293184f5f9bad85178afada22` succeeded with the same counts and complete artifacts. Read-only process evidence
+  still shows PID `11176` started on 2026-08-02 12:20, before the current duplicate-publication source change, so the
+  effective 8766 listener was not replaced. Publish copy was simplified to direct restart-and-retry instructions; no
+  report, database or output mutation was performed by this recheck.
+- The operator's latest `2026-08/01-10` retry, job `087dceca79e64bebb719ad06e7813465`, finished at 15:29 +08 with the
+  same five row counts and the same publish-only failures. At 15:37 +08, TCP 8766 was still owned by PID 11176 under
+  the 2026-08-02 Screen session; the launcher preflight is ready, but the listener still predates the current publisher
+  and job-source modules. The earlier successful five archive/result pairs and current downloads all remain
+  SHA-256-consistent, and six focused publisher tests pass. No restart, rerun, file repair or business-data write was
+  performed; exact listener replacement remains the required operational fix.
+- With explicit operator confirmation, the exact stale PID 11176 was stopped and replaced by PID 54127 at 15:46:29
+  +08 through the existing launcher. One authorized job `05cc547d62854df281b0c9cac60e6f6d` then succeeded at 15:48:37
+  +08 for all five companies with row counts `54/18/7/1/15`; the new job recorded active Booking batch 7 source
+  metadata, reused the same version numbers/artifact descriptors as `c5358fa...`, and all five authenticated HTTP
+  downloads returned 200 with matching archive/current/result hashes. The prior files were not overwritten, the
+  temporary session was logged out, and no Booking/Finance source or fact mutation occurred.
+- Confirmed the source contracts for repeated Booking/report workflows: byte-identical activated Excel uploads reuse the
+  activated source; same rows with different XLSX bytes create a new reviewable source; unchanged report snapshots
+  reuse their complete publication pair; changed Finance or Booking version pins create a new report version; and an
+  activated subset changes Booking detail coverage without deleting the Finance fact rows. Focused source/publisher/
+  integration checks pass 14 tests with two optional ArtifactTool skips. The controlled 8766 replacement and one live
+  5/5 rerun now pass; reboot-persistent supervision remains a separate deployment gap.
+- Confirmed a separate operator-visibility gap: the publisher reuses the archive/result pair internally, but neither
+  `PublicationOutcome`, `CompanyRunResult` nor the public company-job projection exposes a reuse disposition or prior file
+  identity. A successful retry therefore looks like a normal new successful job with a download link; no code change was
+  made in this read-only check.
 
 ## Completed On 2026-08-02
 
@@ -287,8 +348,9 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
   07-20=100, 07-21=119, 07-22=88 and 07-23=109; the user's total was right but the 07-20/07-22 labels were reversed.
 - No database repair was performed during diagnosis. The fixture should be retired from the current projection without
   deleting immutable history, followed by a clean July republication and live API verification.
-- An already-open Channel BI view does not refresh after upload or subsequent tab entry, so it can remain at the old
-  308 value even though the API is 417. This frontend freshness gap is separate from the one-row fixture contamination.
+- Channel BI now checks the selected month's `updated_at` every five seconds while visible, so an already-open view
+  reloads its aggregate data after a new Finance version is published. The historical 308/417 observation above is
+  retained as evidence of the earlier stale-view behavior, separate from the one-row fixture contamination.
 - The BI `公司数` card actually counts worksheet channels; LianTai GROUP/FIT are separate, so six channel keys can still
   correspond to five top-level companies.
 
@@ -372,9 +434,9 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
 - The prior 8766 outage and credential gate are resolved. The current Web process is a detached local Screen session,
   not a reboot-persistent service; `/Users/chillishark/.local/bin/arr2-web-8766 --check` validates its private route and
   Keychain inputs without printing them before a controlled restart.
-- Live authentication/readiness is accepted, but no business mutation was authorized for this activation. One no-PII
-  upload should still confirm migration-013 filename provenance after restart, and one controlled company-report job
-  should confirm processor 1.2.0 produces all five downloads.
+- Live authentication/readiness and one controlled 5/5 company-report job with all five downloads are accepted. One
+  no-PII XML upload should still confirm migration-013 filename provenance after restart; the Web/worker sessions remain
+  detached and are not reboot-persistent.
 - The latest operator-selected Web credentials were rotated on 2026-07-31, but the password still matches the username.
   Rotate it again to a distinct high-entropy value in Keychain, followed by one controlled Web restart.
 - The workstation runs Web and worker as separate processes. The checked-in Compose image intentionally does not claim