feat(dashboard): show passive Topic Memory processing status #2308

Feature description

Implementation sub-issue of #2130: complete the Topic Memory processing-status path from authorized inspection of existing records to a compact status section and details drawer on the Topic Memory page.

The page should answer what input progress and retained blocks are known for the selected Scope, while stating when current execution is not observable.

Problem and proposed solution

Current master already supports Topic Memory browsing, search, exact revisions, durable processing targets, work budgets, retained blocks and explicit retry. The Dashboard does not display these processing facts.

Add the minimum read-only query adaptation needed by this page. Use the existing Scope authorization and consistent read boundary, then render cursor/head/target positions and the current applicable block with safe reason, budget facts, evidence origin and observation time. Keep input progress, executor visibility and retained blocking evidence separate.

The existing recovery status operation is not a passive page-read helper: TopicMemoryRecoveryService.status() calls observe_topic_memory_block(), takes write locks and may materialize a legacy diagnostic record. Preserve its supported recovery behavior; provide a read-only projection for this view without creating or updating business/processing records. If an exhausted legacy allowance has no retained diagnostic, keep that diagnostic unavailable while showing the progress/pending facts that are known; page access must not materialize it.

Acceptance criteria

• Show a compact bilingual Processing status section and details drawer above the existing Topic Memory list, preserving search, pagination, exact-version reading and navigation.
• Read cursor, Source head, retained target and existing block/budget facts for the selected Scope and Topic Memory binding under current authorization. Match blocks to the current frontier and attempt; retried or superseded blocks must not appear as current blockers.
• Distinguish pending inputs, caught-up input consumption, a known retained block and unavailable execution observations. Cursor progress does not establish publication or a no-change outcome; do not show generated-artifact completion percentages or interpret a journal-position difference as an artifact count.
• Show running/retry facts only when fresh observations identify the exact Scope and binding. Otherwise state that current execution is unknown; family-wide worker counts are not Scope evidence.
• Keep query work and output bounded. Inspection performs no model calls, readiness probes, dispatch, retries, allowance changes or business/processing-state writes. Existing authorization/audit behavior remains at its owning boundary.
• Isolate inspection failures from independently readable saved topics. Unauthorized Scope reads and Scope switching must not disclose another Scope's facts.
• Verify pending inputs, caught-up progress without proven output, current and obsolete blocks, explicit retry transitions, legacy missing diagnostics, restart/external-worker uncertainty and passive reads through the actual Dashboard path. Use controlled fixtures; production model calls are unnecessary.
• Document this family/path coverage and each fact's source and limitations in English and Chinese. Share presentation/query logic only where the contract is the same. If a public HTTP contract is needed, use the generated OpenAPI workflow.

Alternatives considered

Calling the existing recovery status operation while rendering would add processing-state side effects to page access. Inferring execution from a pending target or a family-wide Supervisor count would misstate the selected Scope's state. New task tables or a new execution-history model are unnecessary for this slice.

Additional context

Baseline: master bf2ac1fcd9223af7bbab97f8e8e39a269b07fee3, checked on 2026-10-30.

• Topic Memory page
• Dashboard authorization/snapshot lifecycle
• Scope read snapshot
• Existing recovery status
• Retained blocks and recovery

Duplicate check: #2130 is the parent, not a separate implementation slice. #2182 attempted this slice but is closed and unmerged; its implementation and validation claims do not establish delivery on master. All 86 open issues and the changed-file lists of all 33 open PRs were checked. No open equivalent implementation issue/PR was found. #2244 changes Dashboard authorization imports only; #2189 adds processing failure diagnostics rather than this page/query path.

Coordinate available safe reasons and budgets with #2126/#2127/#2128; this slice can use existing evidence without waiting for their complete rollout. It adds no retry/cancel/resume controls, diagnostic export or new durable history. Completion of this slice does not close #2130.