Explain stale mdbase.yaml collection identity when mirror enrollment requires an authority transfer

[callumalpass]

Problem

A folder previously registered as a local collection can retain x-mdbase-connect.collection_id in mdbase.yaml after the associated collection is removed. A user attempting hosted-mirror enrollment reported authority errors and recovered by deleting the entire configuration and recreating the collection.

Deleting the whole configuration is unsafe guidance: it may discard unrelated collection semantics. The original stale/deleted-authority sequence still needs reproduction.

Confirmed code behaviour

At 21d035cc, crates/connect-mirror/src/filesystem.rs::mark_mirror checks mdbase.yaml for x-mdbase-connect.collection_id. Its presence produces local_authority_requires_transfer with:

This folder is a computer-owned authority; transfer it explicitly before mirroring.

The message does not identify the configuration file/key that established that role, or explain how to distinguish a live local authority from stale registration metadata. TaskNotes preserving an existing configuration does not establish that TaskNotes created the Connect identity.

Expected outcome

• Identify the local file/key establishing authority in local CLI/desktop diagnostics.
• Explain the safe next step for a live authority versus an orphaned/stale registration.
• Any repair must verify ownership/state and preserve unrelated configuration; do not recommend deleting all of mdbase.yaml or bypassing authority fencing.
• Add coverage for existing authority metadata and the confirmed stale-registration lifecycle once reproduced.

Related: #345 concerns an in-progress authority transfer blocking collection removal; this issue concerns configuration provenance and safe recovery guidance during mirror enrollment.