#8364 refactor(db): require a transaction for advisory lock helpers

Summary

• acquireAdvisoryXactLock / tryAcquireAdvisoryXactLock took DbOrTx, which also admits the pool-level db. A transaction-scoped advisory lock taken on the pool runs in autocommit and releases immediately, so the caller would run unprotected. No call site did this, but nothing stopped it
• Both helpers and every lock wrapper that forwards to them now take DbTransaction, so that misuse fails at compile time. Also narrowed: the org mutation/membership locks and the MCP transaction lock timeout, the same xact-scoped hazard, and withTransactionRetry's callback, whose argument is always a transaction
• There's no runtime change. Every hunk is a type annotation or import, except three signatures made behavior-identical for every caller:
  • requirePersonalTokenEnrollment(input, lockingTx?) replaces (input, executor, lock); no caller ever passed a tx without locking or locked without a tx
  • loadReviewPreview(row, prepared, lockingTx?): preview still reads on db, resolve still locks FOR UPDATE on its tx
  • the access-request use-case wrapper gives mutations a DbTransaction and reads db, with the same authorize → prepare → tx → lock → re-authorize → execute → audit order
• Responds to a review thread on #8356

Type of Change

• Other: type-level hardening

Testing

• Type-check, lint, and check:audits pass
• Unit suites across every touched module (1,008 files) and 15 integration suites touching the changed modules pass

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)