[V3RON]

Closes #259

simctl runtime delete can answer while simctl runtime list still shows the image as deleting. The iOS driver checked once, at once, so the removal failed although the runtime was gone seconds later.

The iOS remove now lists again every second, on the Clock, while the image is in the deleting state:

• gone: the existing core check passes, and the removal answers removed with its residue;
• listed in any other state: the core check fails at once, as before;
• still deleting at COMPONENT_REMOVAL_TIMEOUT_MS, measured from the start of the delete and never reset, or when signal fires: DriverCrashError, and the record is kept.

isBeingDeleted is the one place that reads the state. It compares it to deleting ignoring case. The exact JSON value still needs confirming on real hardware. Nobody has captured simctl runtime list -j during a delete. The text listing prints (Deleting), and an installed image has "state": "Ready".

docs/CLI.md now says that the removal waits, and when it gives up.

Checklist

• Regression test (the triage test, now passing): "answers the removal with its size and residue when simctl runtime list shows the image as Deleting after simctl runtime delete returns and drops it seconds later (component remove on iOS reports an error although the runtime is removed, because simctl lists it as Deleting for a few seconds #259)".
• "fails when the image is still listed after simctl answered" still fails at once. Its clock never moves, so a removal that waited would never settle.
• New tests cover the budget measured from the start of the delete, the abort (during a pause and during a listing), the one-second poll, the case-insensitive state, and the cleanup of timers and listeners. Each new test was broken on purpose and failed on a named assertion.
• pnpm check is green.

Review

Spec review: 8 findings, 2 fixed. Code review: 7 findings, 6 fixed.

Rejected:

• The JSON state value is unconfirmed — true, and it cannot be confirmed without a real delete. The maintainer checks it on hardware after the merge.
• Comparing the state ignoring case goes beyond the spec — this is deliberate, because the exact JSON value is unknown. The comparison is in one function.
• docs/CLI.md was not asked for — the removal can now take longer and fail in a new way. The deliver rules require the user docs to say so.
• A simctl runtime list call already running is not cut short by the deadline or the signal, so the bound is up to 30 s past five minutes — the wait is still bounded, and the budget is still never reset. The core's own check after the removal runs the same listing. The driver comment and the CLI doc ("about five minutes") say this.

Written by an agent.