fix: exclude checkout operation-lock diagnostics from Nix fixed outputs

[ORESoftware]

Root cause

The checkout-local .zed/operation.lock is a durable rendezvous file whose human diagnostics contain process, host, and timing information. fetchZedDeps copied the complete .zed directory into its recursive fixed output, so two otherwise-identical frozen installs produced different NAR hashes on both Linux and macOS.

The descriptor lock remains the only ownership authority; the diagnostic bytes are deliberately non-semantic.

Fix

• Refuse a symlink or non-regular operation-lock path.
• Remove the regular .zed/operation.lock after the frozen install is complete and before copying the dependency tree into $out.
• Remove the now-empty .zed directory only when no deterministic adapter wiring remains.
• Retain every deterministic .zed adapter file if the directory is not empty.

Validation

The final review delta is one ordinary product file. The normal nix-interop workflow bootstraps the recursive output hash, rebuilds the same frozen dependency graph under two different derivation names, compares both NAR hashes to the bootstrapped hash, and exercises the ordinary offline consumer, incorrect-hash rejection, and tampered-lock canaries on Ubuntu and macOS.

This unblocks the exact-head gates for zed env export mise PR #131 without weakening fixed-output verification.

Superseded PR salvage

Supersedes: none

[linear-code]

DEN-2450