reset-node reuses an immutable attempt-ledger identity

Summary

After a failed node attempt has already been projected into the immutable node-attempt ledger, a same-run resume --reset-node can reopen the same runner attempt identity with different timestamps and state. The next status synchronization then rejects the replacement record even though the workflow is running.

Minimal synthetic fixture

1. Create a temporary Git project with a one-node workflow and a deterministic stub agent.
2. Let attempt 1 fail, then invoke ultrafuzz status --json once so the terminal attempt is projected into the node-attempt ledger.
3. Run ultrafuzz resume synthetic-run --project /tmp/uf-reset-ledger/project --reset-node node:worker --max-concurrency 1 --json.
4. Keep the reopened attempt running long enough to invoke ultrafuzz status synthetic-run --project /tmp/uf-reset-ledger/project --json again.

The status payload reports a running workflow but also returns ok: false with:

NODE_ATTEMPT_LEDGER_WRITE_FAILED
node attempt ["synthetic-run", 42] was already recorded with different immutable data

No model or target-specific artifact is required; the collision is between reset semantics and the generic immutable attempt-ledger contract.

Expected behavior

A reset execution must receive a distinct immutable ledger identity, or be represented as a new reset revision without rewriting the prior attempt row. Historical terminal rows remain unchanged, while status and stats continue to emit schema-valid snapshots during the reopened execution.

Acceptance criteria

• A model-free fixture projects a failed attempt, resets that node, and synchronizes while the replacement attempt is running.
• The prior ledger row remains byte-for-byte unchanged.
• The replacement execution has a distinct stable identity and lifecycle.
• status --json and stats --json do not emit an attempt-ledger write diagnostic.
• Repeated synchronization is idempotent.

Start with the model-free synthetic fixture and reproduce the sequence through resume --reset-node, status --json, and stats --json. Inspect the attempt-ledger handling at those command entry points and verify that the original ledger row is unchanged, the replacement has a distinct stable identity, and repeated synchronization remains schema-valid and idempotent.