lsm/mutation: declared paths beyond 64 bytes deny unlink

[sixtoad]

Defect

A declared linked-worktree metadata path can be opened for writing but cannot be unlinked when the mutation target exceeds 64 bytes.

Sanitized reproduction using the candidate stack from #108:

• Container shape: /worktrees//index.lock
• Gitdir length: 67 bytes
• Lock path length: 78 bytes
• file.open:rw: allowed and audited
• file.unlink: denied and audited
• No credential data was written; the empty test lock was removed after the run.

The file-open index fixed by #108 evaluates the complete declared path, but the shared directory-mutation index retains its 64-byte key and skips longer policy paths. This leaves create/open and cleanup decisions inconsistent for the same declared tree.

Expected behavior

• Mutation authorization enforces declared paths through the public 255-byte file-policy limit without truncation or probabilistic matching.
• mkdir, unlink, rmdir, and both rename endpoints preserve existing deny precedence, directory-self/descendant behavior, audit data, and fail-closed semantics.
• A long declared writable directory permits its intended descendant lock lifecycle while an undeclared same-prefix sibling remains denied.
• The real BPF-LSM verifier/load gate, UID 1001 linked-worktree regression, ownership checks, and container cleanup all pass.

Relationship

Discovered by the Walk dogfood after #108. This issue is limited to mutation authorization; it does not reopen #108 file-open matching or broaden the legacy hard-link scope.