Scope a multi-tenant B2B SaaS with real tenant isolation and billing

You are building Rosterly, a multi-tenant B2B SaaS where every customer signs up as its own isolated agency, not a shared account. Treat tenant isolation as the load-bearing requirement of this build, not a detail to add later.

PRODUCT
Rosterly is for small agencies scheduling shifts for hourly staff. Each agency has its own members, its own data, and its own subscription — no agency should ever be able to query, list, or see a row that belongs to another agency, even by guessing an ID in the URL.

DATA MODEL
- Organization: id, name, slug, subscription_tier (references the tiers below), stripe_customer_id, created_at.
- Membership: id, organization_id (references Organization), user_id (references auth user), role (owner, admin, or member).
- Invite: id, organization_id (references Organization), email, role, token, expires_at, accepted_at.
- Every other business table in this app — Shift, Employee, and TimeOffRequest — must carry an organization_id column and nothing else may scope access to it.

TENANT ISOLATION RULES
Write a row-level security policy on every business table that filters strictly on organization_id matching a membership row for auth.uid() — never on a client-supplied header, a URL parameter, or a value trusted from the frontend. A user with no accepted Membership row for an organization must get zero rows back from every table scoped to it, not a 403 — the query itself should simply return nothing, because a policy that leaks a count or an error message is still a leak. New Organizations are created only through a proper signup flow that creates the Organization and the creator's owner Membership in one transaction, never as two separate steps a signup could fail between.

BILLING
Subscription tiers: Starter ($29/mo, up to 10 employees), Growth ($89/mo, up to 50 employees). Show the current tier and usage against its limits on a Billing settings page, with a Stripe customer-portal link for upgrades and payment-method changes — do not hand-build a checkout form; route through Stripe's own hosted portal. When an organization tries to invite past its tier's employee limit, block the invite and show an inline upgrade prompt instead of silently allowing it.

SCREENS
1. Sign up, which creates the Organization and owner Membership together.
2. An invite flow: an admin enters an email and role, generates an Invite row, and the invited person accepts it into a Membership on their next login.
3. A main workspace view scoped to Shift, Employee, and TimeOffRequest.
4. Organization settings: members list with role management, and the Billing page above.
5. A personal-account switcher if a user's email is a member of more than one Organization.

CONSTRAINTS
Primary brand color: #1F6F5C (deep teal). Use Lovable's native Supabase integration for auth and the database — do not fake multi-tenancy in client-side state or a single shared table filtered only in the frontend query, since that leaves every row reachable by anyone who opens the network tab. Before calling this done, describe in plain language how you tested that a second Organization's data is actually unreachable, not just hidden by the UI.