Enforce tenant isolation in the data layer instead of per route

Every route had to remember to add the business filter to every query;
nothing stopped one that forgot. The audit for this change found several
that had: the M-Pesa status re-check, the stock ledger's duplicate checks,
the daily-inventory and branch-price upserts, a cash-sale replay lookup,
several load-by-id lookups, and every populate().

- tenantGuard: a Mongoose plugin on all ten business-scoped models. Any
  find/update/delete/count/distinct, or an aggregate whose first stage is
  not a $match, that does not pin exactly one businessId throws
  TenantScopeError before reaching the database ($in, $exists and other
  operators do not count).
- crossTenant("reason", fn): the explicit, documented exemption for the
  queries that must span businesses - login's email lookup, refresh and
  invite-token lookups, the M-Pesa callback, the platform console and the
  maintenance scripts. git grep crossTenant lists them all.
- scopedPopulate: populated branch, product and staff names are also
  restricted to the business.
- Every flagged query site now names the business (or is exempted with a
  reason).
- Tests: a check that every model with a businessId field carries the
  guard; the guard refusing unscoped queries of every kind; and a route
  sweep where business A sends business B's ids to every read route
  (nothing of B's comes back) and every write route (all refused, B's
  data unchanged). Test-side database inspections go through db(), an
  explicit test exemption. Removing one route's business filter makes the
  suite fail.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/PILOT_READINESS.md

@@ -157,10 +157,31 @@ platform-wide unique indexes for per-business ones. Until it runs,
 operators cannot open the Platform console and a second business cannot
 reuse an email. It is safe to re-run.
 
+## Tenant isolation is enforced
+
+Every model that holds one business's data carries a guard
+(`src/lib/server/tenantGuard.ts`). A query that does not name exactly one
+business (`businessId: <id>`) throws `TenantScopeError` before it reaches
+the database, so a route that forgets the business filter fails loudly in
+development and in the tests instead of reading or changing another
+business's data.
+
+- Guarded: User, Branch, Product, BranchPricing, Transaction,
+  DailyInventory, Expense, Purchase, StockMovement, StockTransfer. A test
+  fails if a new model with a `businessId` field is added without the guard.
+- Queries that genuinely span businesses must be wrapped in
+  `crossTenant("reason", ...)`: login's email lookup, refresh-session and
+  invite-token lookups, the M-Pesa callback, the platform console, and the
+  maintenance scripts. `git grep crossTenant` lists every one.
+- Related records are loaded with `scopedPopulate`, so a populated branch,
+  product or staff name is also restricted to the business.
+- `tests/isolation.test.ts` sweeps every read route with another business's
+  ids (nothing of theirs comes back) and every write route (all refused,
+  their data unchanged).
+- Not guarded, by design: Business (the tenant itself, always looked up by
+  the session's id), UserSession, MpesaCallbackLog and StockLock.
+
 ## Still open
-- **Isolation by convention.** Tenant filters are still written per route.
-  The tests cover the sales, stock, transfer and access paths, not every
-  route.
 - **Cost of goods is an average.** It uses each product's average buying
   price across the business, not first-in-first-out per branch. Units sold
   with no purchase on record are counted and flagged, but have no cost.