Handle stale Metadata document identities safely

[vrtmrz]

This change validates normal-file Metadata identities before Offline Scanner pair construction, preventing stale document IDs from reaching path-based mutation while allowing a consistent entry for the same logical path to proceed.

Why

A Metadata document can remain readable under its actual local document ID even when the active path service now derives a different ID from its recorded path. An ordinary path-based lookup then addresses another document, or no document at all. Historical renames or path-setting changes may create this state, but this change does not infer a particular origin from the mismatch.

Treating the enumerated stale document as an ordinary path entry can associate reflection, deletion, expired-history cleanup, or last-seen persistence with the wrong identity.

What changed

• Validate each decoded Metadata document against its actual ID before target-file filtering and pair construction.
• Leave an inconsistent document unchanged and outside pair processing.
• Continue ordinary processing when separate, consistent, selected Metadata represents the same case-normalised path.
• Withhold storage processing only when that logical path has no consistent selected Metadata.
• Add a read-only, actual-ID-first Inspector report.
• Add an explicitly invoked one-entry repair which revalidates the exact source revision, writes and verifies the target first, then tombstones the obsolete ID.
• Document the Scanner contract, repair safety properties, and maintained-host boundary.

The change does not add batch repair, rename Vault storage, choose between case variants, coordinate devices, or alter Fast Setup and CLI completion policy. Existing Scanner pair results and the Boolean aggregate remain unchanged.

Verification

• Added the smallest regression test first and confirmed that the previous implementation suppressed the otherwise resolvable path.
• Focused Commonlib tests: 153 passed.
• Commonlib type check passed.
• Generated package build and clean consumer package check passed.
• The exact generated tarball passed the focused downstream LiveSync tests, LiveSync type check, and production build.