fix(components): fence workspace sidebar scope

[wibus-wee]

Author type

• I am an Agent (check this if an LLM agent authored this PR)
• I am a human

Problem / pressure

During a workspace route transition, the route can already target workspace B while the shared workspace identity, runtime, or metadata projection still belongs to workspace A. The state normally converges to B, but consumers can start requests, subscriptions, or effects against the previous workspace during that transient window. Delayed organization work can also attempt to publish an obsolete result after a newer transition has begun.

Summary

• publish workspace slug and id as one versioned context, and reject delayed writes from obsolete revisions
• resolve route-scoped workspace access only when the route target, authoritative workspace id, active runtime, and runtime-owned metadata projection agree
• fail closed for workspace-scoped machine, project, session, sharing, badge, and eager-sync consumers while the destination scope is unresolved
• preserve the existing behavior for consumers mounted outside a workspace route provider
• add deterministic coverage for route transitions, authoritative-id mismatches, and delayed recovery races

Before / after

Before	After
A consumer could briefly remain enabled with workspace A after the route changed to B.	Route-scoped consumers return no workspace id and stay disabled until B's state agrees end to end.
A same-slug cached runtime could remain active after the server resolved a different authoritative workspace id.	An authoritative-id mismatch invalidates the scope until the matching runtime and metadata projection replace it.
A delayed async result could overwrite a newer workspace transition.	Revision-guarded writes ignore results owned by an obsolete transition.
Consumers resumed independently from whichever global value they observed.	Consumers reopen through one shared scope check once the destination state is coherent.

Test plan

• pnpm --filter @lody/components typecheck
• six focused Vitest suites covering workspace context, resolved scope, organization recovery, and visible consumers (37 tests)
• differential Chromium run with agent-browser: the pre-fix consumer semantics reproduced both unsafe enabled windows, while the current implementation failed closed and recovered after state convergence
• oxlint on changed TypeScript files
• prettier --check on changed files
• tsr generate
• git diff --check
• not run against an authenticated hosted-cloud account; the browser exercise injected route, runtime, metadata, and authoritative-id transitions through the real React/Jotai integration

Agent handoff

Instructions for reviewing agents

• Review focus: Inspect workspace-context.ts, use-resolved-workspace-scope.ts, and useOrganization.ts together, then verify every migrated consumer fails closed without blocking provider-external runtime setup.
• Decisions to challenge: Confirm that route target plus authoritative id, active runtime, and metadata ownership are the correct minimum readiness contract.
• Plausible failures / evidence gaps: Authenticated hosted-cloud E2E was not available; focused race tests and a differential browser harness cover the transition logic but not private backend timing.

Authoring context

• User goal / directives: N/A / redacted
• Constraints / non-goals: N/A / redacted
• Risk-bearing decisions: N/A / redacted
• Destructive or irreversible behavior: N/A / redacted
• Deliberately not done or tested: N/A / redacted
• Unknowns / confidence: N/A / redacted

Sharing consent (author side)

• Author-side user explicitly allowed publishing the Authoring context above
• Author-side user explicitly declined publishing Authoring context and understands that maintainers may decline or close the contribution; keep every field as N/A / redacted