refactor(storage): consolidate the two directory-capability stacks

[DecisionNerd]

Found during the architecture audit (sub-agent review).

Finding (MEDIUM)

graphforge-storage re-implements directory capability handling that graphforge-filesystem already provides:

• storage/src/filesystem_admission.rs (2,270 lines): LifecycleDirectory revalidation at :406-470, open_directory_handle x3 platform variants :1235-1262, is_link_or_reparse :1623-1633
• graphforge-filesystem::StableDirectory (filesystem/src/lib.rs:115-559) — and storage/src/durable_rewrite.rs:14 in the same crate uses it
• Admission reuses only the identity primitives (:1635-1650)

Two revalidation protocols (LifecycleDirectory::revalidate vs StableDirectory::revalidate_named) can drift; hardening fixes must be applied twice.

Acceptance criteria

• Admission is a policy layer over StableDirectory (or the split is documented as intentional with the threat-model rationale)
• One revalidation protocol; the other deleted
• Admission evidence tests unchanged and green

Architecture review decision

Treat this as security-sensitive boundary work.

Before consolidation, document the threat-model differences—directory replacement, link/reparse handling, identity stability, child lookup, and platform-specific reopen semantics—and build a shared cross-platform conformance suite.

Additional acceptance criteria:

• Both existing implementations run against the same adversarial conformance cases before deletion
• The retained capability API preserves or strengthens every fail-closed guarantee
• Linux, macOS, and Windows admission/recovery tests remain green