conflicts: decided on what the box holds now, addressed by type and id

[udaychandra]

Spec: sail-conflict-resolve-current. Two defects in sail conflicts resolve, both latent since conflicts shipped, both sail-only.

What was wrong

1. Resolve wrote the snapshot recorded at detection, not the row. Every strategy applies a recorded snapshot (--merge's template is pre-filled from one), so anything this box wrote to the entity after the conflict was recorded was silently reverted — a spec body edited after parking on title, or a run parked while running going back to running after it completed. 0.44.3's per-round re-record narrowed the window; it did not close it.
2. A conflict was looked up by entity id alone, returning null unless exactly one matched. A spec and its room share an id by construction, so parked together both were unresolvable, reported as "No open conflict".

What changed

• One staleness rule, all three strategies. Inside the BEGIN IMMEDIATE transaction ConflictOperations.resolve already opens, the store's live currentForSync snapshot is compared with the conflict's recorded local side, ignoring the store's latestWinsFields() and _ metadata (new pure ConflictDetector.drift). Any drift refuses — nothing written, conflict stays pending:

  'auth' changed on this box after this conflict was recorded (body).
  Run 'sail sync' to refresh it, then resolve.
  

  409 over both the web and local-socket APIs, same message. No --force.

• Conflicts are addressed by (type, id). ConflictOperations.find(type, id); the exactly-one-or-null lookup is deleted. sail conflicts show|resolve <id> [--type <type>]; GET /v1/conflicts/{id} and POST /v1/conflicts/{id}/resolve take ?type=. Without a type, one match resolves as before; several are refused naming them — 'auth' has open conflicts as spec and room: pass --type — as a 400 (ErrorCode.BAD_REQUEST; a bare IllegalArgumentException maps to 422 on the web router). The CLI resolves with the type of the conflict it displayed.

• Main's side gets no guard — it gets tests. The recorded remote only becomes the merge base; the next round three-ways against main's current row.

• Deleted the dead second resolve path in ConflictsCommand (findUnique, resolverFor, choose, apply): test-only callers, and apply was an unguarded copy of defect 1.

Tests

• ConflictOperationsTest (new), conflicts parked over a real paged session (SyncBox.connect + SyncRpcServer):
  • a local edit after detection refuses each of --mine/--theirs/--merge with the exact message and 409, leaving the row, its rev and the conflict row untouched;
  • after a round re-records, the same resolve succeeds and the newer edit is what reaches main;
  • main moved a disjoint field after detection → resolve --mine + a round merges both; same field → parks again with fresh base/local/remote; --theirs + a round lands main's newer value. Main's value is never lost;
  • a spec and its room parked together: refusal names both types, each resolves with its type, and the survivor resolves by id alone again;
  • a run's heartbeat stamping on does not refuse; its lifecycle completing does, and the run stays completed.
• ApiRouterTest: the same spec+room pair through real ConflictOperations — 400 without ?type= (GET and POST), ?type= selects, 409 on a stale resolve, 404 for a type with no conflict. LocalApiRouterTest: ?type= is carried and 409/400 survive the local lane.
• ConflictDetectorTest: drift unit cases.
• Mutation check: with the requireCurrent call removed, 5 of the new tests fail.
• NativeFleetIT is untouched (it resolves immediately after a sync).

Left alone, on purpose

• A round that re-records a conflict while --merge's $EDITOR is open (or between show and resolve --theirs) still lets a decision land on snapshots newer than the ones displayed. Closing that needs a "what was shown" token (the conflict row id) threaded from show to resolve — a design change beyond this spec's rule; worth its own spec.
• --mine on a run rewrites the recorded heartbeat, which may be a few seconds older than the live one; the next stamp moves it forward again.