Release v0.5.10 — burn won't spend the quota you're using (the real 燒爆 fix)

[mixflavor]

The bug (caught by re-reading the dogfood logs)

The 2026-06-04 burn dogfood logged a P0: clikae burn claude <X> → X dry → the reserve walks onto claude/C, the tank an interactive session is live on → the headless job silently spends that conversation's quota. The original "燒爆".

A 2026-06-05 log declared this fixed — but it tested codex only. The "reroute is same-engine, can't hop to claude" reasoning protects burn codex; when you burn claude, the same-engine reserve is the claude tanks, including the active one. Code-verified: _burn_next_same_engine skipped neither the in-use tank nor same-account siblings. A false clear.

Fixes

• P0 — burn's auto-reroute now skips a tank an interactive session holds (live_dir_users, the v0.5.5 phantom-tank scanner). --allow-active overrides; it warns on skip.
• P1 — burn's reserve is account-aware: it skips a candidate sharing an account with a tank it already dried (same login = same quota = already dry; e.g. L→MFC). Reuses _limit_tank_account.

Also

• agy burn-refusal message reads truer ("agy is already global… just use it directly"); clikae tanks footnotes agy as interactive-only / not burnable (2026-06-04 P2).
• docs/HANDOFF-world-class-gaps.md corrected: codex-side isolation note kept, claude-side reroute recorded as fixed-in-v0.5.10 (no longer a false clear).

Tests

tests/bats/burn.bats +4 (P0 skip in-use + --allow-active; P1 skip same-account + a different account stays eligible). bats -r tests = 331/331; shellcheck -S warning = 0.

Lesson logged in the handoff: don't clear a multi-engine bug by testing one engine.

🤖 Generated with Claude Code