fix(store): workspace-level guard for N-hop parent cycles (BUG-2074)

[xarmian]

Summary

BUG-2073 (PR #870) closed the 1-hop A↔B parent-cycle race by folding the child key into a sorted per-endpoint lock batch. But that batch only covers the two endpoints of the edge being written, so an N-hop cycle closed via an edge on an item that neither endpoint locks still slipped past the per-endpoint checkParentCycleQ walk under concurrency (Postgres-only; SQLite serializes all writers via BEGIN IMMEDIATE).

Concrete reproduction: with A→B and C→D already committed, two concurrent adds SetParentLink(B,C) and SetParentLink(D,A) lock the disjoint sets {B,C} and {D,A}, so both cycle walks pass on stale snapshots and both inserts commit — forming A→B→C→D→A.

Fix — workspace-level cycle guard

• acquireWorkspaceParentLinkLock — a Postgres advisory xact lock on a distinct namespace (pad:parent-link-cycle: || workspaceID) that serializes all parent-edge-adding transactions per workspace. With no two adds running concurrently, checkParentCycleQ always walks a consistent, non-racing ancestor snapshot and catches arbitrary N-hop cycles.
• Acquired outermost (before the seq lock and the per-item parent-children batch) in the edge-adding paths — SetParentLink and UpdateItemWithParentLink (only when it actually adds a parent). Global order is cycle → seq → parent-children in every transaction that takes them, so no AB/BA inversion can form. Deadlock-free.
• CreateItemLink was a second, unguarded parent-edge adder: link_type="parent" appended a raw row with no cycle check and no workspace lock — it could form cycles even single-threaded and give a child multiple parent rows (the schema only uniques (source_id,target_id,link_type)), which the single-chain cycle walk can't see. It now routes parent links through SetParentLink, inheriting the full guarded protocol (single-parent DELETE-then-INSERT, workspace cycle lock, cycle check, retry). Non-parent link types keep the append-only insert — none are followed by the cycle walk.
• Scope is edge-adders only. Removals and plain field/status updates can't create a cycle and don't take the lock, so the common UpdateItem path stays un-serialized. BUG-2073's per-endpoint locks remain (they still bound the open-children re-read invariant); the workspace lock is the outer guard.
• Rejected alternative (locking the full ancestor chain per write): complex, deadlock-prone under concurrent reparents, hard to keep in canonical sorted order.

Tests (Postgres-gated where concurrent)

• TestSetParentLink_ConcurrentNHopNoCycle + TestCreateItemLink_ConcurrentNHopNoCycle — build the disjoint-lock A→B→C→D→A quad via parallel goroutines and assert no cycle forms. Both verified to reproduce the bug with the guard disabled (6/64 and 14/64 quads cycle) and pass with it.
• TestCreateItemLink_ParentSingleParentAndCycle (dialect-agnostic) — asserts CreateItemLink(parent) now enforces single-parent (latest wins) and rejects a direct cycle.

Gates

~/go/bin/golangci-lint run (0 issues), go test ./..., and the full Postgres suite (make test-pg equivalent) all green. Two rounds of Codex review addressed (CreateItemLink hole → cycle check + delegation); final review CLEAN.

https://claude.ai/code/session_019knGmnHcx5rrgWXQ8V8DZS