Fail a volume-move fault case whose move was refused#1753

Fixes #1741

A fault case whose move was refused for a reason other than VolumeBusy could pass. If another run tripped the armed fault before the first trigger poll, the harness credited that fault line to the case, reran the move after disarming, and reported passed: true. Only the rerun had moved the Volume.

Changes

run_case fails any case whose first run is refused and names the reply. Busy refusals already become skips, and Release approvals are answered earlier, so any refusal left is a defect. The failure goes through the existing per-case path, which disarms the fault and runs the heal.

Tests

The new test runs kill-snapshot alone. The model refuses the armed volume move with a non-busy error, and writes a fault line right after the post-accept volume runs read, as a sync that started just after that read would.

Before the fix (69915dc), matching the issue's table:

After the fix, both rows fail with RuntimeError: move was refused: {"error": {"code": "internal", "message": "placement exploded"}}:

Gates run: py_compile and the harness unittest suite. The cluster proof runs at the top of the stack.