fix(runner): consume recycle budget only after a successful runner boot #1121

Follow-up from PR #1107 (merged). When the runner is dead mid-request, tryConsumeRunnerRecycle runs before ensureRunnerSession. If the subsequent boot fails (xcodebuild error, simulator glitch), the request's single recycle slot is spent with nothing to show for it; the next command in the same request hits runner_recycle_budget_exhausted without a successful restart.

Problem

In runner-lifecycle.ts, the recycle-budget check/consumption happens at ~L258–264, but ensureRunnerSession at ~L265 can still fail. The per-request recycle budget (~25s boot each) is meant to bound hostile-screen recovery, not penalize transient boot failures.

Suggested fix

Consume the recycle slot only after ensureRunnerSession succeeds, or refund the slot when boot failure is classified as transient (simulator glitch, xcodebuild flake) vs permanent/hostile-screen.

Acceptance

• Unit test: dead runner mid-request → boot fails → same request can still attempt one successful recycle on retry.
• Unit test: hostile screen still exhausts budget after repeated failed recoveries (no unbounded boots).

Context

• Merged PR: fix: bound iOS capture stalls and make runner recovery session-preserving (#1105) #1107
• Motivating issue: Runner resilience under agent-abuse command patterns #1105
• Code: src/platforms/apple/core/runner/runner-lifecycle.ts, runner-recycle-ledger.ts