Enforce automation length caps at the CLI boundary, not on stored rows

[SawyerHood]

What was wrong

bb automation create and bb automation update built the agent and script execution payloads from argv and handed them straight to the service, skipping the request-side Zod length caps that the automations_create/automations_update RPC routes apply. An over-cap --prompt (8,039 chars against the 8,000 cap) was therefore persisted, and the too_big error the user saw came from re-parsing the stored row for the response. Because that same capped schema (automationAgentExecutionSchema) was also used to parse stored rows, every later list, show, and repairing update for the project failed with the same too_big issue, and list took the healthy automations in the project down with it. Report: https://get-bb.github.io/reports/issues/2166.html

What changed

plugins/automations only; no wire change, no CLI flag or knob change.

• src/rpc-types.ts: separated request policy from the stored/response shape. The stored automationAgentExecutionSchema / automationScriptExecutionSchema no longer carry .max() caps. New exported automationPromptRequestSchema, automationScriptRequestSchema, and automationAgentExecutionRequestSchema, plus a script request variant, compose automationExecutionRequestSchema (used by createAutomationInputSchema / updateAutomationInputSchema), so the RPC routes enforce exactly the caps they did before. agentExecutionUpdateSchema is now exported.
• src/cli.ts: the argv boundary parses with the same request schemas the RPC route uses before anything is persisted: automationAgentExecutionRequestSchema for the agent branch of create/complete-update, agentExecutionUpdateSchema for the partial agent update branch, and automationScriptRequestSchema for inline and --script-file content. The whole request is deliberately not parsed with updateAutomationInputSchema: the CLI's script shape carries both script (content) and scriptFile (absolute source path), which the RPC-only "exactly one of script | scriptFile" refinement would reject.
• src/service.ts: list skips a malformed row with a warning, as overview already did, instead of failing the whole project.

Rows that already exceed a cap (the reporter's situation) now parse, so list/show work and update --prompt <short> repairs them.

How you verified

• Added describe("automation CLI length caps (#2166)") in src/automations.test.ts (6 tests, in-memory SQLite, real service + CLI registration): over-cap --prompt on update and create is rejected with nothing persisted and the project stays usable; over-cap inline --script on create and update is rejected before the snapshot file is written; a seeded over-cap row stays listable, showable, and repairable; service.list skips a malformed row and warns; the RPC request schemas still reject over-cap prompt/script on create and update while the stored schema accepts an over-cap prompt. With the fix stashed, all 6 fail (6 failed | 78 passed); with it, 84 passed.
• pnpm exec turbo run typecheck test --filter=bb-plugin-automations: green.
• Live, against an isolated dev instance of this branch (scripts/bb-dev-app current, pnpm bb:dev): reran the report's scenario. update --prompt <8039 chars> exits 1 with too_big and the stored prompt stays at 19 chars; create with an over-cap prompt and with a 262,145-char --script both exit 1 and create nothing; list/show keep working. Then seeded the over-cap prompt directly into the row via sqlite to mimic a pre-fix victim: list shows both automations, show exits 0, update --prompt 'short again' exits 0 and the stored length becomes 11.

Fixes #2166

AGENT GENERATED: by Claude Opus 5