fix(dag): vs-deletion adoption tail — adoption can slip past a workflow's own deletion within the revalidation window

[LeXwDeX]

Tracked from the v1.0.13 release notes (PR #268) and the DAG-LOC-01 evidence probes.

Symptom

An instance that has just passed the ownsWorkflow revalidation (durable row read) can still act (spawn/publish) on a workflow that gets deleted in the window between the ownership check and the action. The single-authority design narrows but cannot eliminate this tail without making adoption itself atomic with the row state. SpawnReady eviction is the current mitigation: a deleted workflow's node spawn is evicted before execution.

Why it was pinned, not fixed (v1.0.13 decision)

Same root territory as #269 (SessionMoved wedge): both need an atomic-DB-adoption/deletion state machine — a workflow's terminal/deleted transition must fence concurrent adoption in one transaction, not via a check-then-act read.

Acceptance

• A deletion committed after a passed ownership check fences the in-flight adoption action (no post-deletion spawn/publish survives) — either via transactional fencing (e.g. conditional update claiming an adoption lease on the row) or an equivalent provable barrier.
• Deterministic race probe(s) in the park-gate harness style (see C2/C6 and the H1 probe ab4cddb) that go RED when the fencing is reverted.
• All existing DAG-LOC-01 guards stay green.

Note: coordinate design with #269 — the two likely share the adoption-state-machine redesign.

[LeXwDeX]

Fixed by PR #272 (merged to dev 2026-08-15T02:12Z, promoted to main via #274, released in graphagent-v1.0.14). tryClaimAdoption: single conditional UPDATE fenced to non-terminal statuses, gated after ownsWorkflow at both adoption sites and at spawn re-admission — a workflow's deletion can no longer be slipped past. Probe C7 with mutation evidence M4/M5 in the PR body. Documented residual (bounded re-stamp-vs-adoption race, time_updated wall-clock bump) carried as a known non-blocking follow-up in the release notes.