[TWS-02] Add TWS secondary repository and thread grouping #10

ID: TWS-02 (F-003). Priority: P1. Blocked by: #9. Backlog: #1.

Scope and reuse

Add a secondary TWS presentation under upstream canonical repository groups.
Use shared client grouping helpers and existing scoped project/thread routes,
not tags as an alternative identity system.

Acceptance criteria

• Repository -> feature -> stack/worktree views retain every physical
  environment/project/thread target. A multi-repository feature may appear
  under each relevant repository without merging its scoped identities.
• Unbound/ambiguous items remain reachable in an explicit ungrouped section.
  Unavailable/stale TWS retains last-known labels with visible freshness;
  turning grouping off restores the normal repository view.
• Logical feature context and current execution location remain distinct.
  Archived/unmaterialized nodes display context without a bogus "open worktree"
  action. Exact context set/clear/reassign uses TWS-01 commands.
• Web/desktop lists and applicable command/project selectors use the shared
  grouping model. Mobile uses a compact native hierarchy/filter rather than
  copying a desktop tree. Navigation always carries owning environment IDs.
• Lazy-load bounded topology; do not invoke TWS CLI per row or expand all thread
  histories. Provide accessible labels, keyboard/native navigation and stable
  expansion state. Repository grouping without TWS is unchanged.
• Tests cover collisions, multi-repo features, ungrouped fallback, stale data,
  grouping disable, mobile selection and navigation to two same-named hosts.

Coverage and non-goals

Provider-independent, web/desktop/mobile, all existing remote modes. Integrated
client evidence requires permission. No custom federation, tag-based routing,
TWS/worktree mutation, hosting API integration or global feature IDs.