9b51f5ae29
Adds a design document for supporting admins who manage 2+ specific brands (e.g., franchise / multi-brand tenant use cases). Current model: admin_users.brand_id is a single UUID | null, and the effectiveBrandId = brandId ?? adminUser.brand_id ?? null pattern silently does the wrong thing for multi-brand admins. There is no central validation that an admin is acting in a brand they have access to. Proposed: admin_user_brands junction table (m:n), kept admin_users.brand_id for backwards compat, a new multi_brand_admin role, a cookie-based active brand, a centralized brand-scope helper, and a BrandSelector dropdown in the admin header. ~30 server actions and ~10 page server components get a mechanical one-line swap to use the new helper. Follow-up migration 220_drop_legacy_brand_id.sql will drop the legacy column after we verify nothing reads it. Out of scope for this spec. See docs/superpowers/specs/2026-06-04-multi-brand-admin-design.md