Runner transport resend keys on the caller-facing retriable flag #2862

Problem

flagged_retriable in packages/platform-apple/src/runner/runner-error-classification.ts derives the transport's "same-session resend" verdict (retryable) from the caller-facing details.retriable flag. These are different facts:

• details.retriable tells a caller's poll (for example wait, wait-polling.ts) to try again.
• retryable tells runner-client.ts to resend the same request.

#2852 had to add an order-dependent app_not_running row just to undo the conflation for APP_NOT_RUNNING.

Today the conflation also resends:

• startup-phase failures that carry retriable: true (runner-cache-metadata.ts:115, :320: runner_phase_budget_exhausted, apple_toolchain_probe_unavailable) for read-only commands, up to 3 times, each with a fresh startup budget, which works against the fix(ios): budget cold toolchain probes for the first-exec signature stall #2423 cap;
• external runner providers' retriable: true errors.

Proposal

Make flagged_retriable key on the fact it means: details.runnerErrorCode === RUNNER_BUSY_RUNNER_CODE (renamed runner_busy). Then delete the app_not_running row. Move the pin in runner-error-classification.test.ts (the generic-flag resend case) and decide explicitly whether startup-phase and provider errors should be resent.

Found in the thermo-nuclear review of #2852; kept out of that PR because it changes retry behavior beyond it.