feat(api): add API keys with bearer auth and a per-key rate limit

[josue-commits]

Summary

Adds API keys to API v1 so integrations can call the API without a browser session. Members create and revoke keys per workspace, send them as Authorization: Bearer dforms_..., and each key gets its own rate limit. Forms now record whether they were created from the web app or the API.

Changes

• db: api_key table (only the hash is stored, key_hash is unique-indexed), list/create/resolve/revoke helpers, a cap of 10 active keys per member, and form.created_via written on create and duplicate.
• api: Bearer key authentication for dforms_ tokens. Session callers take the exact same path as before. The workspace header must match the key's account; a revoked key or an inactive member gets 401.
• api: /v1/api-keys routes (list, create, revoke) with role and workspace rules. The key in clear appears only in the POST response.
• api: a route allowlist for key callers (KEY_NOT_ALLOWED on other routes), enforced from real route metadata with a drift test.
• api: per-key limit reusing the public limiter; the 121st call in a row returns 429 with Retry-After.
• api: created_via: 'api' on forms and via: 'api' on form_created / form_published events.
• docs: OpenAPI documents the bearer scheme and the key routes.
• Changeset for the published packages.

How it was tested

• Typecheck and lint green.
• Full pnpm test on SQLite green (api 776, db 363, web 1248).
• Full @quill/db suite on Postgres 16.
• New race test: 15 parallel creates for one member hold the 10-key cap on both dialects.
• commitlint and DCO sign-off on all commits; publish-gate passed.

Review notes

An independent review found one issue, now fixed (3e78c77): on Postgres, the INSERT ... SELECT ... WHERE count < 10 was not atomic under READ COMMITTED, so parallel creates could exceed the per-member key cap. The insert now runs in a transaction behind a per-member advisory lock, and a race test covers it.

Left as follow-ups (not required by the spec):

• Keys of a disabled or removed member still list as active, and re-enabling the member makes them work again (they return 401 while the member is inactive). Whether disabling should revoke keys is a product decision.
• Unknown dforms_ keys are not rate limited, since the per-key limiter runs after a key resolves.
• On a route outside the allowlist, an invalid key gets 403 KEY_NOT_ALLOWED before the 401 check (fails closed).

🤖 Generated with Claude Code