Issue #237 opened: Ideas: deploy --wait, execution output modelling, friendlier 5xx mapping, diagnose_app deploy-status cross-check

Grab-bag of improvements surfaced by a real production session (2026-07-02: deploy + migrate + one-off-command work on the crunch app). Each is small and independent; split out as needed.

1. deploy should optionally wait and report the outcome

Tonight's webhook deploy failed silently (build container OOM-killed, exit 255) while the old container kept serving — the app looked fine, the deploy was dead. The deploy tool returns a deployment_uuid and walks away. Add wait: boolean (poll deployment get until terminal, return final status + failure tail from logs) or a dedicated watch_deployment tool. An agent that deploys without watching WILL ship "site 200 = deployed" false positives. (This exact failure mode is common enough on this estate that it's in the operator's memory notes.)

2. Model (and expose) scheduled-task execution output

ScheduledTaskExecution (src/types/coolify.ts:1188) has no output field, but the live API returns the command's stdout in message. Add the field to the type, mention it in the list_executions description, and consider a get_execution action for single-execution fetch. Without knowing stdout is in message, agents assume output isn't available at all.

3. Status-code-aware error mapping in request()

src/lib/coolify-client.ts:512 renders bodyless failures as HTTP 500: Internal Server Error. For an agent, a bare 500 is a dead end. Map known cases: 500 on scheduled-task create/update → mention the command-length limit (#234); 401/403 → token scopes hint; 404 on {uuid} routes → "check resource type vs uuid". Small lookup table, big agent-experience win.

4. diagnose_app should cross-check the latest deployment

An app can be running:healthy while its most recent deployment is failed (tonight's exact state — old container serving, new code never arrived). diagnose_app already fans out; add "latest deployment status vs running container age" and flag the mismatch explicitly ("running container predates the last (failed) deployment — the app is serving stale code").

5. (Meta) response-size guardrail

#232 is the acute case, but a general invariant test — "no tool response may exceed N KB with default params" — would catch the next projection bypass before an agent's context pays for it.