[Fix] Flatten submit_automation_work_items to one work item per call

[daniel-lxs]

Problem

Staging ci-failure-triage task 0urhx5qrifwj7 (grok-4.5 on opencode-server) correctly diagnosed the GHCR CI failure, then failed ~15 consecutive submit_automation_work_items calls and looped for over an hour without submitting anything. Slack report: https://roomote-dev.slack.com/archives/C0AJZ8TR6T1/p1783709608450479

The failed calls cycled through:

• readinessMessage rejected as too_big (>500 chars) — reasoning monologue leaked into the optional field, and one bad optional field rejected the whole submission
• workItems sent as a JSON string instead of an array, items missing required fields
• 400 "Act automation work items must include executionPrompt." from the platform API — the tool schema marks executionPrompt optional, so the requirement only surfaced as a generic post-round-trip error

Same failure class as the manage_environments empty-arguments fix (#8): some models can't reliably emit deeply nested tool arguments. The fix that worked there was simplifying the schema, not validating harder.

Change

submit_automation_work_items now takes one flat work item per call — scalar params only, called once per work item. The worker wraps the item into the platform API's existing workItems array; the API contract is unchanged.

• executionPrompt, targetRepositoryFullName, and targetEnvironmentId are required in the advertised schema, so models see the real contract up front instead of a post-hoc 400
• workspaceReadiness and readinessMessage are removed: the platform derives readiness from targetEnvironmentId and rejects bare_repo for act items, so an automation could never legitimately set them — readinessMessage (the field that wedged the staging loop) was pure dead weight on this tool
• disposition stays as an optional enum(['act']) because the scan prompts instruct models to pass it; the handler hardcodes act (and suggest now fails with a crisp enum error)

Testing

• New automation-work-items-tool-schema.test.ts: valid item accepted, every field is a flat string/enum (regression guard against re-nesting), the act-item requirements are schema-required, disposition compat, uuid validation, and the params→API mapping
• submit-automation-work-items.test.ts and tool-descriptions.test.ts pass unchanged; tsc --noEmit, prettier, eslint clean

Follow-ups (not in this PR)

• Scan prompts still describe batch submission wording ("submit up to 3 work items with...") — still correct since the model just calls the tool N times, but the disposition/suggestion-rejection wording could be cleaned up per the prompt-editing policy
• submit_task_suggestions keeps the old nested array shape and could get the same flattening
• No retry cap on scans: a model that keeps failing tool calls still loops; worth a separate guard

🤖 Generated with Claude Code