Household Foundation / D: Switch between households + tenant context

[rudingma]

Parent: #111 · Milestone: Household Foundation
Implementation order: 2 of 6

User story

A user who belongs to multiple households can switch the active one. Every query, mutation, and UI they see is scoped to the active household.

Decides

• Active-household persistence mechanism (JWT claim / HTTP header / cookie / DB column / client state — one will be chosen)
• Switcher UX (dropdown in shell / dedicated screen / modal) — integrates with App Shell nav on mobile and desktop
• Cross-session persistence — does the active household survive logout/relogin?
• Tenant-context injection — request-scoped active-household context (likely nestjs-cls, per docs/data-layer-design.md)
• Row-level scoping pattern in household-scoped repositories — every such query filters by active household
• Service-layer guards preventing cross-tenant access

Inherits

• household_memberships data (Story A, Household Foundation / A: Create a household and become its lead #113)

Shared assumptions (locked by scoping session 2026-04-22)

• Tenant-context plumbing lives here, not in a standalone infra story.
• D is implementation-ordered second (immediately after A) so all subsequent stories (E1, B, C, E2) are written with tenant-context-aware code from inception. No retrofit.
• The patterns D establishes (middleware shape, repo scoping style, context-access conventions) become shared assumptions inherited by later stories.

Out of scope

• Per-feature UI differences based on grants (Story E2, Household Foundation / E2: Grant enforcement + lead-side edit UI #118)
• Enforcement of grants in API resolvers (Story E2, Household Foundation / E2: Grant enforcement + lead-side edit UI #118) — D ships tenant-scoping plumbing; grant-gating sits on top of it
• What specific data in other features is tenant-scoped (per-feature concern)