[Optimization] Recording phase consumes 25–37% of iteration token usage

[Alizen-1009]

Problem

Ordinary-iteration phase telemetry shows that the recording phase consumes
25–37% of total backend-reported token usage across three clean optimization
rounds.

Round	Recording tokens	Terminal tokens	Share
v1	248,374	673,157	36.90%
v2	335,461	1,059,130	31.67%
v3	219,313	875,641	25.05%

For v1, recording usage was:

• input: 24
• output: 2,686
• cache read: 240,646
• cache write: 5,018
• total: 248,374

Most recording usage is repeated cache/context processing rather than newly
generated output.

Recording currently includes

• candidate accept/reject decision
• candidate rollback
• memory/vN.json generation and repair
• plan/search-log updates
• git status / git diff
• commit creation
• final worktree checks
• terminal handoff

Repeated model turns across these operations replay an increasingly large
session context.

Goal

Reduce recording-phase token processing without changing:

• correctness/performance acceptance
• memory completeness
• Git cleanliness
• rollback behavior
• campaign authority
• auditability

Investigation directions

1. Measure recording substeps separately:
   • decision
   • memory write
   • Git writeback
   • final verification
2. Avoid repeatedly reading full memory and Git output.
3. Produce one compact structured recording payload before writeback.
4. Collapse memory/plan/Git operations into fewer model-tool turns.
5. Evaluate whether deterministic helpers can own purely mechanical writeback
   while the Agent still owns conclusions and evidence.
6. Do not estimate savings from wall time; compare backend-reported usage.

Success criteria

• recording token usage reduced by at least 30% on a representative campaign set
• no increase in invalid memory records or dirty worktrees
• no change in candidate acceptance/rejection outcomes
• no extra Agent or GPU sessions
• results validated across more than one backend where usage deltas are available