[vrtmrz]

This adds an incremental file-name index and a host lookup contract so collision checks can reuse path identities across content-only edits.

Related to vrtmrz/obsidian-livesync#1346.

Changes

• Export FilePathIndex and the shared name-query types through /storage. Preserve original path spelling and every collision candidate under the existing Legacy/NFC and case policies; update materialised identity buckets through membership deltas.
• Add the optional IFileSystemAdapter.fileNameLookup capability and forward it through file access. Hosts without it retain the listing fallback, including request sharing and invalidation when the storage-event count or comparison policy changes.
• Make targetFilter request identity candidates instead of rebuilding its own whole-Vault map. Keep collision rejection and the existing narrowly scoped bypass behaviour.
• Request fresh supported listings for reconstruction preflight. The host continues to own readiness, observation, physical-path validation, and metadata freshness.
• Separate fallback operations into named functions with explicit dependencies, document the contracts, and cover policy changes, membership updates, failed reads, and overlapping requests.

Compatibility and adoption

The adapter capability is optional. Direct implementations of StorageAccess must implement the new findPathIdentityCandidates() method when adopting this pre-1.0 interface. Existing getFileNames() callers remain valid; { fresh: true } invokes the host's supported listing authority.

The CLI and Obsidian integrations are in the companion Self-hosted LiveSync PR #1351. The index itself owns no watcher, filesystem I/O, persistent storage, or file metadata. Non-indexed hosts retain their current fallback costs.

Validation

• npm run check:types.
• npm test -- --maxWorkers=1: 3,793 tests passed.
• npm run test:package, including the packed exports and consumer checks.
• Downstream Self-hosted LiveSync checks, units, and production/CLI builds against the unpublished packed candidate.
• Fallow complexity inspection and type/runtime import-cycle review.

The downstream checks use a locally packed candidate; this PR does not publish a package or designate the current registry version as containing these APIs. Package publication and exact downstream dependency adoption remain separate steps.