feat: warn the agent at 80% of a run budget before hard stop

[salignatmoandal]

Summary

The budget already existed. The agent never saw it until the run was killed.

• Warn once at 80% of max_cost / max_tokens / max_time, then keep going.
• On the next turn the model gets a system message so it can cheapen tools, summarize, or finish instead of slamming into the hard stop.
• The budget_exceeded JSON contract and kill-switch at 100% are unchanged.

Why this is interesting

enforceBudget was a fuse, not a policy. The runtime already counted cost, tokens, and time (record / snapshot / per-agent spend), but the model only learned the ceiling after iterationStop. From the user's point of view that looks like a crash: Execution stopped after reaching budget.max_cost.

That is the EcoAgent-Bench gap: completing under a budget is not the same as choosing economical actions. A kill-switch with no feedback trains the agent to spend until the wall.

This PR turns the counters into a signal inside the loop — a change in agency policy, not an extra log line.

Before	After
Budget = kill-switch	Budget = signal + kill-switch
Agent is blind until death	Agent can still adapt
Counters unused by the model	Counters feed the next prompt

What that buys docker-agent:

1. Fewer runs cut mid-task (code, MCP, delegation).
2. Less waste: the agent can stop repeating tools or finish sooner.
3. A reusable primitive: the runtime can now talk to the model from a metric. Soft budget today; later, model routing or denying expensive tools.

What it does not claim:

• It does not pick cheaper tools by itself — it gives the LLM the information.
• It does not add YAML (80% is an internal constant, no schema bump).
• It does not relax the ceiling. Ignore the warning and the 100% stop still fires.

Behavior

At the existing turn-boundary check in RunStream:

1. If any ceiling is hit → same as today (budget_exceeded + assistant stop message + iterationStop).
2. Else if a limit is in [80%, 100%) and that tracker has not warned for that limit yet:
   • emit the existing Warning event (TUI / JSON stream)
   • append a system message the model will see on the next GetMessages call
3. Each tracker warns once per limit (cost, then tokens, then time — same priority as exceeded()).
4. Unpriced spend still does not invent a cost warning (the existing unpriced Warning remains).

Test plan

• go test ./pkg/runtime -count=1 -run 'TestBudget|TestNilBudget|TestEnforceBudget|TestRecordBudget'
• go test ./pkg/runtime -count=1 -run 'TestBudgetExceededEventJSONContract|TestEnforceBudgetWarnsOnceThenStillHardStops'
• task test
• task lint

[aheritier]

👋 Some commits in this PR are not signed and verified by GitHub. Please sign your commits with a GPG or SSH key registered in your GitHub account, then force-push.

Commits that are not verified: 8858c9a

See GitHub's guide on signing commits for setup instructions. I've added status/needs-signed-commits; it will be removed automatically once every commit in this PR carries a valid GitHub-verified signature.

[aheritier]

Prompt-cache concern: this persists the 80%-budget warning as a system message in session history (pkg/runtime/budget.go:506). That rewrites the cached system/instructions prefix for Anthropic, Bedrock, and ChatGPT/Codex; with num_history_items, trimming can also relocate it ahead of the conversation. The first call after warning may therefore require a full-context cache write at exactly the point this feature is meant to limit cost.

Please route this through the existing transient extraSystemMessages mechanism instead of persisting it, using stable wording to preserve cache reuse. This also avoids stale/accumulating warnings after session resume and loss of the warning after compaction.

Separate blocker: CI lint is currently red (budget_wiring_test.go:245, use assert.Len).

@dgageot @rumpl — requesting your eyes on the prompt-caching implications, as this is a nuanced provider-level behaviour.

[aheritier]

👋 This PR has merge conflicts with the base branch. Please rebase or merge the latest base branch and resolve them. I've moved it to draft and added status/needs-rebase; it'll be picked back up automatically once the conflicts are cleared.