bug: chat_with_agent reports a usage-limit 429 as agent_busy although the turn already ran, so a retry repeats its side effects #3244

Summary

TrinityClient.chat() turns every HTTP 429 from POST /api/agents/{name}/chat that the gate parser does not claim into {queue_status: "queue_full", retry_after}, and runAgentChat answers it as agent_busy — "Please wait N seconds before retrying". Two different 429s reach that branch. The admission refusal (CapacityFull, X-Trinity-Error-Code: capacity, queue_length in the detail) dispatched nothing, so a retry is right. The usage / rate-limit 429 from _apply_sub003_autoswitch comes after the agent already ran the turn: the execution row is written failed with its salvaged cost, then a 429 is raised with the classified error code (sometimes "Subscription auto-switched … Please retry."). Reported as agent_busy, the caller retries the whole message and repeats whatever the partial run already did.

Context

• src/mcp-server/src/client.ts, chat(): if (response.status === 429) → queue_status: "queue_full" for every 429 the gate parser did not claim.
• src/mcp-server/src/tools/chat.ts, runAgentChat: 'queue_status' in response → status: "agent_busy".
• src/backend/services/chat_execution_service.py: the post-run 429 (_apply_sub003_autoswitch, raised after the failed row with salvaged cost) vs. the admission 429 in src/backend/routers/chat.py (CapacityFull, header capacity, The 503 skip-laundering fix has a twin one status code over: 18 bare 429 skips still hide an exhausted subscription #2919).
• Found by the PR feat(delegation): every caller is taught that a receipt means running — never re-send on silence (abilityai/trinity-enterprise#568) #3240 review (abilityai/trinity-enterprise#568). That PR's delegation contract now tells callers that an error without an execution_id — agent_busy included — is not proof that nothing ran, and to check list_recent_executions before re-sending. This issue makes the label itself honest.

Acceptance Criteria

• agent_busy is answered only for an admission refusal (X-Trinity-Error-Code: capacity), never for a 429 raised after the agent ran
• The post-run 429 surfaces as its own result that names the failed execution, so the caller can read it with get_execution_result, and does not tell the caller to retry
• A test drives both 429 shapes through the real chat() and runAgentChat and asserts the two answers differ

Technical Notes

• client.task() throws API error (429) for the /task route's 429s; worth checking for the same split while there.