fix(ai-providers): cap AI_PROVIDER_KEY_CREATE/UPDATE apiKey length

[pedrofrxncx]

Reduction/hardening: none of AI_PROVIDER_KEY_CREATE or AI_PROVIDER_KEY_UPDATE bounded the length of the apiKey field before it's hashed (SHA-256) and encrypted (AES-256-GCM) into the vault and stored in Postgres — every other string field on these tools (label, presetId) has a .max(), but apiKey had none.

Why it matters: an authenticated org member could submit an arbitrarily large string as an "API key" (megabytes), and it would be hashed, encrypted, and persisted as a DB row with no bound — a resource/DoS gap of the same shape as the other attacker-controlled-string-length caps already fixed in this codebase (see the apiKeys/registry tool schemas, which do cap their key/secret fields).

Fix: added .max(4096) to apiKey in both AI_PROVIDER_KEY_CREATE and AI_PROVIDER_KEY_UPDATE input schemas — generous enough for any real provider API key/token (these are typically well under 200 characters) while closing the unbounded-write gap. Pure input-validation tightening; no behavior change for any legitimate caller.

Regression test: apps/api/src/tools/ai-providers/key-length-bound.test.ts asserts a 4097-char key is rejected on both tools and a 4096-char key is accepted.

To verify: bun test apps/api/src/tools/ai-providers/key-length-bound.test.ts apps/api/src/tools/ai-providers/key-create.test.ts

Locally ran: bun run fmt, cd apps/api && bunx tsc --noEmit (clean), the targeted test file above (16 pass), and bunx oxlint on the three changed files (0 warnings/errors). Full CI validates the rest.

---

Summary by cubic

Caps the apiKey length on the AI provider key create and update tools to prevent unbounded string writes. Previously any length was accepted; now keys over 4096 characters are rejected.

• Adds a regression test covering the new limit on both tools.

^{Written for commit 1cd9f5a. Summary will update on new commits.}

[pedrofrxncx]

Closing as stale: this PR sat past the bot's 48h merge window, main has moved on, and its CI results no longer reflect the current base. This is a housekeeping close, not a rejection of the change — if the underlying problem still exists, the bot will find it again and open a fresh, rebased PR.

[studio-bot:stale-close]