Refactor tenant-domain UI ownership between smrt-tenancy and smrt-users

[willgriffin]

Summary

@happyvertical/smrt-tenancy currently contains some Svelte/UI pieces that look more like tenant domain UI than generic tenancy infrastructure. We should clean up that boundary without merging smrt-tenancy and smrt-users.

Problem

The intended architectural split appears to be:

• @happyvertical/smrt-tenancy: generic multi-tenant infrastructure (context, decorators, interceptors, adapters)
• @happyvertical/smrt-users: tenant domain models and auth/RBAC concerns (Tenant, Membership, roles, permissions, sessions)

But smrt-tenancy currently includes UI that depends on smrt-users, for example:

• packages/tenancy/src/svelte/components/TenantCard.svelte imports Tenant from @happyvertical/smrt-users
• packages/tenancy/src/svelte/components/TenantSwitcher.svelte imports Membership and Tenant from @happyvertical/smrt-users
• packages/tenancy/src/ui.ts declares module metadata for Tenant / TenantCollection, even though those models are owned by smrt-users

That makes the package boundary fuzzy and makes smrt-tenancy feel higher-level than it should be.

Proposed Direction

Do not merge smrt-tenancy and smrt-users.

Instead:

1. Keep smrt-tenancy focused on infrastructure only
2. Move tenant-domain UI ownership into smrt-users (or another tenant-domain package if we later introduce one)
3. Ensure smrt-tenancy main/runtime entrypoints stay independent from smrt-users
4. Reserve smrt-tenancy for generic tenant scoping that other packages can depend on without pulling in user/tenant domain models

Candidate Changes

• Move TenantCard and TenantSwitcher out of packages/tenancy/src/svelte
• Re-home those components under packages/users/src/svelte if that is the best fit
• Update module metadata so tenant model ownership is declared by smrt-users, not smrt-tenancy
• Revisit any docs/readmes that currently imply smrt-tenancy owns tenant models or tenant UI

Acceptance Criteria

• smrt-tenancy exports only generic tenancy infrastructure and optional infra-oriented helpers
• Tenant-facing UI components live with the package that owns Tenant / Membership
• Package boundaries are clearer in docs and exports
• No new circular package dependencies are introduced

Notes

This is boundary cleanup, not a request to combine the modules. The current separation is useful because many SMRT packages can depend on smrt-tenancy without needing smrt-users.