fix(core): the operator reset finishes when one device has no driver

[V3RON]

Closes #660

Status

Implement: done (8/8 in nuke-service.test.ts; pnpm test:changed 4387 passed) Review: round 1, 0 open Hardware: n/a Gate: merged
Done: merged as f5b5b01

What is this?

simlock nuke stopped at the first device whose platform has no driver: NoDriverError escaped the reset loop, every device after it stayed booted, and the command reported failure. One device that cannot be reset is now logged and the reset goes on.

How does it work?

NukeService.#runNuke catches around the per-device #resetDevice call only — the inline shape #664 landed in the cleanup reaper, no shared helper. A maintenance or release-all failure still rejects the run, and the finally still reopens admission. NukeService had no logger; it takes an optional one now, wired where create-core.ts builds it, and the device it could not reset is logged at error with its id, platform and error.

Done when

• The reset does not abort on a device whose platform has no driver and still resets every device after it — the triage reproduction, carried unchanged from bug/660-repro, is green: both driverless records are passed over and the healthy device after each ends deleted, across both verbs. Reverting the catch reddens it on NoDriverError.
• The new branch has its own path test, as a strict area needs — "logs a device it cannot reset at error, naming the device, platform and error". Deleting the log line reddens that test alone.
• A maintenance or release-all throw still rejects the run — "reopens admission even when reset work fails" is untouched and live: widening the catch over the whole loop reddens it.

src/core/AGENTS.md's Nuke item states the isolation and stays within its 150-line budget. No end-user doc claimed nuke fails when one device cannot be reached, so none changed; no event changed.

Assumptions

• Assumption: exit status of simlock nuke with a device it could not reach — it now exits 0 with the failure only in an error log; this follows from the fault isolation the triage chose and no doc says otherwise. docs/CLI.md's nuke section and exit-code table checked: neither states that nuke fails when one device cannot be reached.

Review

Spec review: 0 blocking, 0 fixed, 1 note. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes.
Rounds: 1. Tokens: n/a.

Kind full, so all three reviews ran; the code reviewer with lens: both in its own worktree of d54b86b5. Inputs came from .agents/scripts/review-inputs.sh 668 (rules, ADRs and briefs from main), and the reviewers saw no PR body, no commit messages and none another reviewer's output.

How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649, #650 and #661. The reviewer agent ran instead as a fresh detached claude -p session on bug/660 — its definition from .claude/agents/reviewer.md, its model from that file's frontmatter — which spawned the three reviewers itself as its own fresh sub-agents, each reading only the inputs directory and its own worktree of the reviewed commit. Nothing was reviewed by the agent that wrote the code.

Written by an agent.

[V3RON]

Review notes

Not blocking, not verified. Each is one reviewer's claim.

• spec: assumptions.md:1 nuke exits 0 when a device reset throws and the failure is only in an error log (recorded as an Assumption; reviewer judged it conservative)

Written by an agent.