docs(plan): make API key limit atomic

[dirtybits]

Summary

• document the concurrent read-then-insert gap in POST /api/keys' five-active-key limit
• define a small additive database-helper approach that serializes per-wallet create-key operations
• specify route, regression, rollout, rollback, and blocker requirements without changing runtime behavior

Verification

• git diff --check main...HEAD
• verified the plan frontmatter, stable pending todos, exact affected files, acceptance criteria, rollout, and rollback sections

Deferred implementation

The plan intentionally defers the code change because it requires a serverless/Neon transaction-semantics validation before altering the API-key database path. No database operation, dependency change, authentication-flow change, or chain action was made.

Plan: .agents/plans/api-key-active-limit-atomicity.plan.md

---

Note

Low Risk
Documentation-only; no production code, schema, or auth behavior changes.

Overview
Adds an execution plan (.agents/plans/api-key-active-limit-atomicity.plan.md) for a future fix; no runtime or database changes in this PR.

The plan records that POST /api/keys today enforces the five-active-key cap with a separate SELECT of non-revoked keys and a later INSERT, which concurrent valid create requests can race past. It specifies an additive create_api_key_with_active_limit PL/pgSQL helper in web/lib/db.ts (per-owner pg_advisory_xact_lock, count, then insert in one transaction), a single helper call from web/app/api/keys/route.ts after nonce consumption with the same 400 quota message, and focused route/schema tests. Rollout, rollback, blockers (Neon/serverless lock semantics), and explicit out-of-scope items are included; implementation stays deferred until those are validated.

^{Reviewed by Cursor Bugbot for commit 76ccb16. Bugbot is set up for automated code reviews on this repo. Configure here.}