fix(server): close a D1 limit, a consent replay, and the CRM's missing bounds

[dcondrey]

Five findings from auditing the CRM after #41, plus the dashboard tab that finally consumes it. The first two are defects that would have reached production; the third is a hole in a security property the code claimed to hold.

The company rollup 500s on any account with 99 or more linkable contacts. D1 refuses a query carrying more than 100 bound parameters, and the consent lookup binds site_id and now on top of one per contact — so it asked for 101. COMPANY_ROLLUP_MAX_CONTACTS was set to 100 as though the whole allowance were available. It is a hard failure, not a slow one, and it lands on precisely the largest account rather than on the small ones a test reaches for. Verified against a live probe rather than from the docs alone: 98 ids plus 2 fixed binds passes, 99 fails with too many SQL variables. The events queries had the same defect and no cap at all — their IN list is the union of every linked contact's live salt windows, so it is contacts multiplied by windows, and a single contact could reach it on any deployment that raises RAW_RETENTION_DAYS.

All three now chunk, and the merge is written so the aggregate stays exact. Totals add; first and last seen take the extremes across chunks rather than whichever chunk finished last. The path ranking deliberately does not take a per-chunk top ten and merge the survivors — a path in the overall top ten need not be in any single chunk's, so that returns a plausible and subtly wrong ranking. The covering test is built on exactly that case: /sleeper is rank 13 in both chunks and rank 1 overall, so a prefix-and-merge implementation drops it entirely.

A genuine consent statement authorized the wrong person. The CRM link grouped consent records by the external_user_id COLUMN and authorized them by the SIGNED claims, and nothing tied the two together. The claims name a site, a tier and a visitor hash but never the uid — external_user_id_present is a bit, not a value — so a real, deployment-signed grant for one person satisfied every check when filed under another contact's id. Signature verification cannot catch it because nothing is forged. The comment on that function asserted the property held; it did not, and the two existing forgery tests both used an invalid signature, so they proved only that the signature check runs.

Concretely: the per-contact export returns consent statements verbatim, by design, as cryptographic evidence. Copy one into a consent_records row naming a different uid and that contact's analytics page shows the first person's browsing. The binding turns out to be recoverable rather than absent — the identified pre-image is uid:<uid>|salt|siteId and the claims carry the salt window — so the hash is now recomputed from the row's uid and required to equal the signed one. A missing salt fails closed, and that cannot strand a live grant: retention drops a consent record at granted_at < cutoff and its salt only at window_end < cutoff, and a window always ends after the grant inside it, so the salt outlives the record. Salts are read without getScopedSalt, which mints one when absent — a verification that conjured the salt it was about to check against would resurrect an identifier retention had destroyed.

/api/crm is the only route group returning names, emails and phone numbers, and it was the one with no limits on it at all. Every global middleware in app.ts is path-scoped to /api/collect or /api/experiments, so none reached it: no rate limit, no body limit, and an offset with a floor and no ceiling. One stolen analyst session could pull the entire contacts table — total comes back on the first response so the page count is known immediately, each page is 100 complete records including up to 4000 characters of notes per person, and nothing bounded the request rate. The limiter is keyed by the operator, not the site: everything else here keys per site because the risk there is one tenant drowning another, but a per-site key would let a compromised session hide inside its team's traffic while punishing colleagues for it. It sits after the role guard at every route, matching /api/event's deliberate ordering, and the tests assert an anonymous caller sees 401 rather than 429.

Three smaller ones found in the same pass. A capped rollup answered reason: no_linked_contacts, which is a claim about contacts it never examined — now none_linked_within_cap. deleteCompany captured the company name before the transaction, so a rename committing in between stamped every contact with the superseded name, with the company row then deleted and nothing left to correct it against; the name is now read by a correlated subquery inside the batch, and the unlinked count is taken inside the transaction instead of materialising one row per contact through .returning() to produce a single integer. Erasing a contact wrote to two databases in the order that loses data: a failure on the second write destroyed the only record of which uid to erase, stranding consent rows holding that person's raw identifier — the exact data the request was about. Erasing consent first leaves a retryable state. A foreign-key violation reached the client as a 500 when it is the caller losing a race with a concurrent company delete. And ContactUpdateSchema dropped the identifier invariant ContactCreateSchema enforces, so a PATCH could blank email, external id and name and leave a row that can never be matched, deduped or erased — NULLs being distinct in both unique indexes, nothing downstream would object.

The dashboard now consumes all of it. A CRM tab with contacts and companies as master/detail, searchable, status-filtered and paged. The states that carry the design: a 501 is the default for any deployment that never bound CRM_DB, so it renders as a calm "not installed" panel naming the binding, with no alert role and no retry; linked: false renders its reason plus an explicit note that it is not a report of zero activity, and the figures are not drawn at all; the company rollup always shows "N of M contacts linked" above its numbers so one-of-twelve cannot read as the account's traffic. Auth is the session cookie through a new sessionFetch that deliberately sends no Authorization header, since these routes refuse API keys.

That surfaced one more server gap. The browser cannot learn its own role for a site — /api/auth/me reports a role per team, and no session-reachable route maps a site to its owning team — so the first version inferred admin only when every membership granted it. Sound, but it hides the delete button from anyone who is admin on one team and viewer on another. The server already resolved the exact role to authorize the request, so the list responses now report it.

What the risk is not: no schema change, no migration, no new identifier, no change to ingest or to any analytics table, and no change to what a deployment without CRM_DB does. The consent kernel change is a tightening — it can only reject links that were previously accepted, and the test asserts the rightful owner still resolves, because a check that severed real links would pass a one-sided test.

Every new safety assertion was mutation-checked: each guard disabled in turn, confirming exactly its covering test fails, then restored. That includes the two D1 limits and the foreign key, which are pinned by live probes rather than by documentation — I checked that D1 actually enforces both before relying on either.

Two process notes. The bind-limit regression test passed on the first run because without a signing key the consent lookup returns before it ever builds the query; it only became a real test once given a key, which is why "make a new passing test fail on purpose" is in the standard. And a biome check --write run from inside apps/dashboard reformatted lib/worldGeo.ts, which the root config deliberately ignores as minified generated data — caught and reverted before it shipped.

pnpm lint, pnpm typecheck, pnpm test green: 1583 tests across 174 files, up from 1537.