Fence fold publications to the active advisory lock session

[Nitjsefnie]

Summary

Fence every repository publication on the advisory-lock server session that admitted its reconciliation, so a fold that loses that session cannot overwrite a newer result.

Related Issues and Pull Requests

Fixes #210

Changes

• Capture a reconnect-proof coordination-session identity and carry it in a per-store asynchronous reconciliation scope
• Lock the repository row and verify the exact advisory-lock owner before identity, availability, cooldown, and materialization writes
• Preserve existing public store signatures, queue-lease semantics, CLI reconciliation, and short work-pool transactions
• Add real PostgreSQL coverage for stale identity and materialization writes, loss without takeover, publication ordering, fallback paths, non-superuser visibility, and concurrent repositories

Testing

• pnpm exec vitest run tests/fold tests/db/schema.test.ts tests/db/fold-revision.test.ts tests/db/reconciliation-lock-release.test.ts --maxWorkers=4 — 29 suites and 785 tests passed
• pnpm exec tsc --noEmit — passed
• ESLint over all nine changed TypeScript files — passed
• Ownership-decision mutation — both stale-write regressions failed as expected
• Repository-row-lock mutation — publication-ordering regression failed as expected

Follow-ups / Known Limitations

• Existing cleanup through an unprimed, disconnected reserved coordination handle can remain pending; this change fences its publications but does not change that handle lifecycle.
• A short publication transaction admitted before session loss may finish, but its row lock forces any successor publication to commit afterwards.
• Already-running old binaries still contain unfenced publication code; deployment must replace the old worker population.

Footer

Generated by GPT-5.6 Sol (brief, orchestration), GPT-6 Astra (discovery, implementation, testing, verification)