bmersereau adds a second lock to Mike's database

A defense-in-depth rewrite so that one careless permission can't quietly expose a table to the outside world.

Today Mike's data is protected by a single blanket rule that revokes client access. The problem: one stray permission - added in a future update, a hotfix, or a click in the Supabase admin dashboard (Supabase is the hosted database service the app runs on) - can silently undo that for a table, with nothing to stop it. bmersereau's proposal adds a second wall so a slip-up no longer opens the door.

The change bundles a few pieces:

A deny-all rule on every table that blocks client-side reads and writes even if a permission is accidentally granted.
An automatic guard that applies the same protection to any new table added later, so nothing can be added unprotected.
A check script that fails loudly if any table is left uncovered.
A migration with a matching rollback, so live deployments can adopt it without a full rebuild.

Normal app traffic is unaffected, since the backend connects with privileged access that bypasses the rule. bmersereau also flags that a competing proposal, which would let the frontend query the database directly, is philosophically incompatible - and asks the team to pick one model before either lands.