Port implementation status and lazy snapshots from #460

[MaggieAppleton]

Ports two backend pieces from @Krzysztof-Cieslak's #460. Both commits carry his co-author trailer.

#460 will be closed. Its interactive task-graph UI and workspace picker are superseded: the team chose #508's Build capsule and view, and #451's rule that work runs on whoever clicks Build. These two pieces stand on their own and are worth keeping.

What is kept

1. hasGraph on implementation status. Plan.ImplementationStatus (protocol first) gains hasGraph: boolean, and implementationStatus() derives it from the latest graph version's tasks. It rides on plan:implementation and the plan:open reply, so a client can tell a graph exists without fetching a full snapshot. Krzysztof's test checks that it publishes only after the durable commit and survives reopening.
2. useImplementationSnapshot (apps/web/src/implementation-snapshot.ts). Full snapshots load only while an implementation view is active, and responses for another room or an older revision are ignored. It refreshes on the frames its caller names (by default plan:implementation, plan:open, plan:update and experiment:changed) and exposes read() for an immediate fresh read. After the rebase onto main, Make Build plan explicit and show build status in one capsule #508 loads Build's snapshot in useBuildPlan (build-plan-button.tsx), which the header capsule, the Build tab and the Build view all share. useBuildPlan now uses the hook in place of its inline fetch and reload logic, with the same behaviour: the same reload frames, the throttled reload on edits, and the fresh read after a draft turn ends. implementationResponse and implementationEndpoint stay in build-start.ts.

hasGraph has no consumer yet: room-workspace's plan:implementation handler only uses locked, and Build reads the full snapshot. It is left as an available field (room-workspace's initial status just includes hasGraph: false).

Merge order

This merges after the living-document stack (#451 → #452 → #453 → #508 → #510/#454 → #457 → #466 → #520), which has now landed. It has been rebased onto main, and the hook is adopted in #508's shared Build state rather than in build-view.tsx, which no longer fetches snapshots itself.

flowchart LR
  A[Build view active?] -- no --> Z[No fetch; in-flight request aborted]
  A -- yes --> F[GET /api/channels/:room/implementation]
  F --> S{Same room and older revision?}
  S -- yes --> X[Ignore stale response]
  S -- no --> U[Set snapshot, call onLoad]
  W[plan:implementation / plan:open / plan:update / experiment:changed] --> R[refresh: abort current, refetch]
  R --> F

Loading

Tests

• bun test apps/server/src/tasks apps/web/src/build* (69 pass, includes new notifications.test.ts)
• bun test full: all pass except three design-token/icon audits that flag local, uncommitted design-jig files
• bun run types clean
• bun run ci: only a design-jig CSS custom-property finding (local jig file, not in this PR)
• bun run e2e e2e/implementation-launcher.e2e.ts: 11 passed, 1 skipped

🤖 Generated with Claude Code