[Feature]: Tracking: add a read-only hierarchical Roadmap projection to Kanban

## Problem or Use Case Kanban operators can inspect execution one board at a time, but cannot see a compact, evidence-backed rollup of how authorized work relates across scopes, what dependency is critical, or which decision is next. For example, an operator overseeing several projects should be able to move from a portfolio summary to the blocked task and its evidence without introducing another scheduler or source of truth. This is adjacent to #88571's compact Kanban information architecture, not a replacement or duplicate: that issue improves the existing board; this issue tracks an optional hierarchical Roadmap projection over it. ## Proposed Solution Add an optional `Board | Roadmap` view to the existing Kanban API and its Desktop/WebUI clients. ### Authority and minimal scope - Kanban tasks, dependencies, runs, reviews, and events remain the execution ledger and scheduler. - Roadmap is a read projection only. It cannot create, schedule, approve, close, or redefine work. - Add optional stable scope entities with parent references. The supported vocabulary is `company → portfolio → workstream (client | product | experiment) → project → epic → sprint → board`; task/subtask remain existing Kanban tasks. - Levels may be omitted. Scope ancestry never gates dispatch, and task dependencies remain in the existing dependency graph. - Extend the existing Kanban plugin API rather than adding a service or standalone app. Desktop and standalone WebUI consume one versioned contract and fixture corpus while adapting layout per surface. ### Compatibility Existing `project_id`, `tenant`, board identity, task links, and unscoped tasks continue to work. Scope metadata and task/board bindings are nullable and additive. When metadata is absent, existing APIs and board behavior remain unchanged; legacy project/board/tenant values may be projected through documented read-only fallback precedence without rewriting task rows. An unavailable scope catalog must not damage or hide task/run/event truth. ### Deterministic progression - Status, health, critical path, blockers, and momentum are computed from authorized visible records and expose their raw components, freshness, and provenance. - Verified outcomes are deduplicated by stable task revision/evidence/event identity. Creation volume, tool calls, runtime, agent count, and raw done-card count score zero. - Momentum may use a documented time window and decay formula, but must never rank agents or scopes. - Dependency cycles, partial reads, stale data, unauthorized scopes, empty scopes, and unavailable external maturity/evidence authorities fail closed and remain visibly distinct. - Achievements, if rendered, require versioned definitions and structured evidence references. No prose matching, blind increments, leaderboard, XP economy, streak pressure, or reuse of activity-volume achievement state as authority. - Optional generated narrative is default-off, provenance-labelled, and presentation-only; it cannot write task, metric, evidence, or approval state. ### Responsive interaction Use one compact, summary-first hierarchy at every width. Wider viewports add comparative columns, an aligned timeline, and a selected-evidence detail pane rather than inflating cards. Narrow viewports retain the same-density list and open context in a drawer/sheet. Roadmap rows and evidence links should return to a removable Board filter. Preserve 44px touch targets, visible focus, semantic names, reduced motion, Back/Escape dismissal with focus return, and no page-level horizontal overflow. ### Acceptance criteria - [ ] Fresh and upgraded board fixtures preserve existing unscoped behavior with no automatic row rewrite. - [ ] Invalid parent order, cycles, dangling references, and concurrent first-open migration are deterministic and fail closed. - [ ] Board/profile authorization is applied before aggregation; hidden sibling boards affect neither counts nor denominators, and unauthorized scope lookup does not leak existence. - [ ] Rollups expose source revision/event IDs, freshness, warnings, raw metric components, and deterministic replay/idempotency behavior. - [ ] Outcome deduplication, zero-volume scoring, decay/window boundaries, negative rework, dependency ties/cycles, empty/partial/stale states, and evidence-gated achievements have focused tests. - [ ] Existing board create/patch, `/board`, events WebSocket, CLI, dispatcher, and worker flows pass unchanged when scope capability is absent. - [ ] Desktop and standalone WebUI share contract fixtures and state/action semantics; capability mismatch degrades to Board without data mutation. - [ ] Interaction and overflow evidence covers 320, 360, 390, 430, and 1280px, including hierarchy navigation, timeline/detail enhancement, contextual sheet, keyboard/touch paths, Back/Escape focus return, stale/error retry, and non-empty seeded data. - [ ] The projection batches by authorized board rather than task (no N+1 task reads) and remains responsive on a documented large fixture. Suggested implementation slices: 1. Versioned scope/projection contract, additive compatibility layer, canonical authorization/aggregation, and thin API adapter. 2. Desktop and WebUI adapters sharing contract fixtures and semantics. 3. Optional reporting only if separately justified after the deterministic projection is useful. ## Alternatives Considered - Reusing task dependencies for hierarchy conflates context with execution gating. - Encoding hierarchy in tenant strings, project records, or every board's metadata lacks stable shared ancestry or creates divergent copies. - A second roadmap task/event ledger risks conflicting lifecycle truth. - Reusing activity-based achievement state rewards volume without evidence. - An LLM-first summary is non-deterministic and cannot safely own progress or approval. ## Non-goals - No second ledger, scheduler, nested dispatcher, or duplicate task table. - No mandatory hierarchy, automatic migration, or hierarchy inferred from names, paths, tenants, or dependencies. - No replacement of Projects, boards, tenants, dependencies, workflows, or the existing achievements dashboard. - No worker competition, leaderboards, arbitrary XP, streaks, confetti, or generated-prose mutation. - No broad Kanban redesign beyond the compact Roadmap controls; #88571 remains the board IA predecessor. - No standalone app or new service. ## Feature Type Other ## Scope Large (new module or significant refactor) ## Contribution - [x] I'd like to implement this myself and submit a PR