feat: support transaction locking on mounts without hard links

[apackeer]

Summary

Stacked on #1107; the base is fix/config-filesystem-lock.

Config can now proceed when a compatible mounted filesystem rejects hard links. Transaction locking automatically falls back to an owner-stamped directory, while a local process gate serializes acquisition, recovery, execution, and release.

This removes the reported hard-link blocker. It is bounded compatibility support, not certification of arbitrary S3 filesystem drivers: the mount must still provide the file semantics required by AI-DLC.

Changes

• Coordinate native and directory transaction locks through a dedicated local, receipt-managed gate keyed by the canonical project root.
• Keep .aidlc-transaction.lock as the destination lock path so existing file-lock owners remain protected.
• Recover directory owners only with valid same-host/boot metadata and a provably dead PID. Preserve live, foreign, incomplete, invalid, and replacement owners.
• Probe exclusive creation, mutable append/readback, descriptor identity, file replacement, directory rename, Unix file permissions, workflow locking, and synchronization.
• Recheck capabilities before directory-lock transactions apply changes. Report the failed operation and storage remediation; retain the existing rename-based transaction and rollback logic.
• Document storage requirements, driver limits, and the single-host/single-mount coordination boundary.

User experience

For a mount whose missing hard-link operation was the blocker, first-run config, refresh, and workflow writes can use directory locking without a new flag.

All cooperating processes must use one continuously running mount on one host, a common local temporary directory, and the same PID namespace. This is not a distributed lock across independent mounts or hosts.

The filesystem still supplies coherent identity/append behavior and atomic replacement/rename semantics. Successful probes cannot prove crash durability or atomicity. Mountpoint lacks operations needed for full workflows; s3fs implements rename through copy/delete and does not establish the full atomic-rename contract. Those limitations are documented explicitly, and this PR adds no copy/delete emulation of a failed rename.

Checklist

• I have reviewed the contributing guidelines
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented

Test plan

• bun scripts/package.ts
• bun scripts/package.ts --check
• bun run typecheck
• bun run lint
• Targeted unit slices with bash tests/run-tests.sh --debug -P 8 --unit --filter ...: 215 passed, 0 failed across installation/configuration (94), transaction filesystems and concurrency (43), first-run/installed-workflow behavior (41), and coverage registry (37).

Tests disable hard links throughout all setup subprocesses and then exercise config, refresh, installed intent creation, state changes, and audit writes. They also cover multiprocess exclusion, interrupted-owner recovery, rollback, capability rejection without project changes, and local-gate release recovery.

Validation uses isolated filesystem fault injection around real file operations. No live S3 mount was exercised, and the reporting user's mount driver remains unknown.

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.