MJAPI JS heap OOM during prompt failover storms (22-candidate retry loop accumulates multi-MB contexts)

Observed twice during runtime verification for PR #3296, on runs with NO branch involvement (so not specific to that feature):

- An agent run whose prompt failed repeatedly entered the failover loop ("Trying candidate N/22") with a multi-MB conversation context. Combined with the agent loop's up-to-50 iterations, MJAPI's heap grew monotonically until `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` — first at the 4GB default, then again with `--max-old-space-size=8192`.
- Crash log tail shows the OOM landing mid-stream-read during candidate 10/22 of iteration 10 of a Query Strategist sub-agent whose action kept failing (agent-authored SQL error), i.e. a retry storm: ~10 iterations × up to 22 failover candidates, each attempt carrying the full multi-MB message array.
- Persisted step data stays small (KBs) — the growth is in-memory state retained across failover attempts/iterations.

Suggested investigation: what per-attempt state AIPromptRunner retains across failover candidates (request/response buffers, failover attempt records referencing full message arrays), and whether the agent loop's consecutive-failure guard should trip before memory does.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start with AIPromptRunner and the agent loop described in the issue, then reproduce the prompt-failure retry storm while observing heap usage. Trace request/response buffers, failover attempt records, and full message-array references across candidate retries and iterations. Done means the retained state is identified and the consecutive-failure behavior prevents the reported heap exhaustion.

Written by the indexing model from the issue text.