fix(cat): the two prune deletes named the row but not its owner

[catomean]

Closes finding 13 of #563.

Both prune paths in the Cat memory service deleted purely by id:

.from(CAT_MEMORIES).delete().in('id', ids)

Safe today — and only conditionally so. The ids come from a query already filtered to this user, run through an RLS-scoped client. Neither condition is stated by the code doing the deleting. Three other paths in this service already use getAdminClient(), where RLS is not a backstop at all; hand one of those to a prune and it deletes across users, silently, from a function whose job is routine cleanup nobody watches.

Every other delete in these files already filters on user_id — including the suppression-lifting one twenty lines above pruneIfNeeded. Both prunes now do too.

A gate, because the finding named one and there were two

recordForgottenFacts says "same pattern as memory pruning" in its own comment, and had inherited the gap along with the pattern. That's why this adds check:user-scoped-deletes to verify rather than making the same edit a third time later.

Deliberately narrow: the Cat memory service, where every table is strictly per-user. Widening it needs a per-table notion of ownership that doesn't exist yet, and a gate that has to guess is a gate that gets muted.

Proven to fail before shipping: reverting either prune exits 1 naming the file and line; the clean tree exits 0 over 6 deletes.

Severity, stated accurately

Latent, not live. I checked the callers: extractAndStoreMemories and rememberFacts are both handed the request-scoped client. The admin client appears in chat-orchestrator.ts but only for meterCreditUsage. So nothing crosses users today — this closes the door before someone changes the client, which is exactly when it would stop being noticeable.

73 Cat suites (1031 tests) and type-check green.