fix(driver): price reclaim by the strategy it actually runs

[V3RON]

Closes #56.

What was wrong

estimate("reclaim", spec) returned 1s for iOS and 2s for Android against a measured ~34s simulator erase. Both consumers were misled in the optimistic direction — a waiting requester's ETA, and the stalled-transition threshold, which at 1s could never clear its own 60s floor, so the "derived from the driver's own estimates" property #37/#55 asked for was not in effect for reclaim.

Two of the three acceptance criteria turned out to describe consumers that were never wired up, so fixing the number alone would not have shown anywhere:

• estimatedReclaimMs was hardcoded to 0 in both timing helpers — estimated_reclaim_ms has always been a literal zero in the grant payload.
• The reclaiming progress stage is documented in docs/CLI.md and typed in the contract, but nothing in production emitted it. Only a test ever pushed one.

The change

estimate now takes a DriverEstimate rather than a bare operation name, so reclaim carries the clean level reclaimStrategy already selects on. All figures below are measured, not derived — see the measurement section.

driver	clean	strategy	estimate	measured
iOS	standard / full	erase	34s	~34s (#43)
Android	standard	snapshot	6s	2.4–5.1s, median 4.6s (n=9)
Android	full	wipe	32s	22.8–42.8s, median 31.7s (n=5)

Wiring the two dead consumers:

• estimatedReclaimMs carries what releasing the device will cost — the one figure in a grant's timing that describes work still ahead of the holder rather than work already done. Set for provision, boot-shutdown, and (new) warm grants, which previously reported all zeros.
• The reclaiming stage is emitted when a waiter is queued and a spec-matching device is currently being reclaimed. Purely informational: the plan is untouched and the device is granted through the normal ready path when its reclaim commits.

Doctor takes the slower of the two clean levels. A reclaiming record does not say which one started it, and the errors are not symmetric — too tight invents a false stall, too loose only delays a real finding. With the measured numbers this now matters in practice: Android's reclaiming threshold is 32s × 3 = 96s and clears the 60s floor, where the earlier guesses left it landing on the floor exactly as before this work. iOS clears it at 102s.

sameSpec moved to domain.ts; it was already duplicated in the planner and the warm-pool coordinator, and this needed a third copy.

Measurement

Run on an M3 Pro / 38 GB, AC power, Android emulator 36.5.11.0, Pixel 8 / API 35 (android-35/default/arm64-v8a), instrumented through simlock's own device.reclaimed / device.ready events rather than by timing SDK calls externally.

A wipe reclaim is ~10× what this PR first guessed, and the guess was wrong about what the number measures. reclaim itself does only shut the emulator down and defer the wipe to the next makeReady — that part of the original comment was accurate. What it missed is that the device does not leave reclaiming there: WarmPoolCoordinator#disposition re-readies a device the pool wants to keep warm before committing the transition, so the wipe boot and the baseline re-capture fall inside the same window. That window — not the driver call — is what both consumers of this estimate observe: the age Doctor compares against, and how long a waiting requester actually waits. The estimate now models the window.

It is bimodal: a device the pool does not keep warm settles in seconds. The slow branch is the one quoted, because under-quoting makes every kept-warm reclaim look stalled while over-quoting only delays a finding.

Other numbers from the same run, unchanged as a result:

• Cold boot 22.5–29.5s (n=3) against a 31s estimate — a safe upper bound on this hardware.
• Provision 0.9–1.5s (n=3) against 1s.
• Three concurrent snapshot reclaims: 3.7s, 4.5s, 5.7s — contention is mild at this pool size.
• No device.purge-failed or device.quarantined events, no failed boots.

SNAPSHOT_BOOT_ESTIMATE_MS (4s) remains unvalidated — a snapshot boot needs the device shut down first, and daemon stop deliberately leaves emulators running (the warm pool survives a daemon restart; idle.shutdownAfterMs is what shuts them). It only feeds a diagnostic log threshold, so it is not load-bearing here.

iOS cold boot: 30s → 60s

Separate from #56, and a judgement call worth flagging. A cold simctl boot to bootstatus measures 30–60s depending on the machine, and the quoted ETA should not be the best case. The cost is that Doctor's provisioning stall threshold widens with it — (0.5 + 60) × 3 ≈ 181s, up from ~91s — so a genuinely hung boot goes unreported for roughly twice as long. That is the cheaper of the two errors, but it is a real trade-off rather than free safety; happy to revert this half if you'd rather keep the tighter threshold and quote the median instead.

Tests

• iOS: reclaim priced as an erase at both clean levels.
• Android: strategy split, at the measured values.
• Doctor: a full-level reclaim past the standard threshold is not a stall; past the full one it is.
• LeaseEngine: a waiter queued behind a reclaim gets queued then reclaiming with the driver's ETA; a waiter queued behind a leased device gets only queued.
• LeaseEngine: grant timing carries estimatedReclaimMs, including for a warm grant that does no work.
• e2e: the reclaiming stage all the way out to the CLI's stderr — coordinator, daemon push, and rendered eta_seconds. This was the one new user-facing output with no coverage past the coordinator, and an attempt to observe it on real hardware missed the branch (three AVDs in the pool meant the second request booted a spare instead of queueing). Verified to fail when the notification is removed.

pnpm check green (typecheck, typecheck:e2e, lint, format:check, 642 unit, 33 e2e). fallow reports no new findings on the changed files.