Add filesystem-backed inode boundary integration test

[chubes4]

Remaining test gap after #974

PR #974 completed the runtime scope originally tracked here:

• target-ref-aware projected inode demand before mutation
• tracked checkout and dependency bootstrap reservations
• independent byte/inode admission floors and safety margin
• bounded inode hotspot diagnostics and resource-aware emergency selection
• GNU/BSD portable inode probing with typed unknown behavior
• serialized concurrent admission and post-rebase revalidation

One integration-test gap remains: exercise Git lock creation on a genuinely inode-constrained filesystem fixture at the exact admission boundary. Existing tests verify the arithmetic and create index.lock, but the host filesystem itself is not constrained to one inode above the refusal floor.

Acceptance criteria

• Build a bounded disposable filesystem fixture with a deterministic inode ceiling, when the test environment supports it.
• Verify admission refuses when projected demand would consume the final Git safety margin.
• Verify an accepted operation can create the expected Git lock at the exact safe boundary.
• Skip with explicit typed evidence when the runner cannot create the fixture; do not weaken unit coverage or production guards.
• Keep the fixture isolated from the DMC workspace and production paths.

Constraints

• Do not duplicate dependency planning from feat: enforce workspace inode capacity #974 or workspace bootstrap: lazy + deduplicated dependencies — keep disk light at high worktree counts #791.
• Preserve null/unknown inode semantics on unsupported filesystems.
• This is test hardening, not a runtime blocker for the merged feat: enforce workspace inode capacity #974 behavior.