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

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.