Harden connection storage reads for unknown future versions

Start at ConnectionStorageService.fromStorageItem() and inspect the existing v1 wrapper, v2 compatibility path, and v3 reconstruction path. Add focused real v1, v2, v3, and future-version fixtures covering preservation, read-only behavior, and non-sensitive diagnostics; done means unknown additive versions avoid wrapV1AsV2() without changing known-version behavior.

Problem

ConnectionStorageService.fromStorageItem() currently uses an exact version switch:

• 3.0 reconstructs the current storage shape.
• 2.0 uses the v2 compatibility path.
• default assumes an unversioned v1 record.

The default branch therefore conflates two different cases:

1. item.version is absent, which is a genuine v1 record.
2. item.version is present but unknown, such as a future 3.1 or 4.0 record.

Treating an unknown future record as v1 is destructive. A v3-shaped record sent through wrapV1AsV2() can lose folder membership, flatten the selected authentication method to Native authentication, drop structured credentials and Entra ID metadata, or skip a folder whose connection-string slot is empty. If the degraded item is later saved, those losses can become persistent.

This blocks a safe storage version bump. Older released versions cannot be changed retroactively, so a tolerant reader must ship and reach the relevant preview/release cohort before a new version is written.

Goal

Make the current reader forward-tolerant for future storage versions that remain additive-compatible with the newest known shape. Unknown version strings must never enter the unversioned-v1 path.

Recommended sequence

1. Ship a tolerant reader. Distinguish a missing version from a present-but-unknown version. Only a missing version uses the v1 wrapper. A present unknown version is read as the newest known additive-compatible shape, with a non-sensitive diagnostic signal.
2. Let the tolerant reader roll out. Wait until the release reaches the users who may switch between preview and older builds.
3. Bump the storage version later. Choose 3.1 or 4.0 based on the intended compatibility semantics. At that point the number is naming rather than a downgrade hazard.

Implementation scope

• Refactor fromStorageItem() so the unversioned v1 case is explicit rather than the default branch.
• Preserve the existing 2.0 and 3.0 behavior.
• Route a non-empty unknown version through the newest known reconstruction path only when the record is additive-compatible with that shape.
• Emit a non-sensitive warning or telemetry classification for an unknown version so future-format reads can be measured.
• Keep the conversion read-only. Reading an item must not persist a migration or rewrite its version.
• Document the compatibility contract: assigned secret indexes are append-only, never reordered, and never reused.

Acceptance criteria

• An unversioned v1 fixture still uses the v1 compatibility path and preserves its expected fields.
• A v2 fixture still uses the v2 compatibility path.
• A v3 fixture still reconstructs directly.
• Unknown-version fixtures such as 3.1 and 4.0, shaped additively like v3, do not use wrapV1AsV2().
• An unknown-version connection preserves parentId, selectedAuthMethod, connection string, and every known authentication config.
• An unknown-version folder remains a folder and is not skipped because its connection-string slot is empty.
• Reading an unknown-version record performs no storage write.
• Unknown-version handling emits no connection strings, credentials, tenant IDs, client IDs, or other identifiers in logs or telemetry.
• Focused tests use real v1, v2, v3, and future-version storage fixtures.
• A later version bump remains a separate change after the tolerant reader has shipped.

Out of scope

• Choosing or applying the next storage version number.
• Supporting a future format with breaking, non-additive shape changes without an explicit converter.
• Removing the legacy v1/v2 wrappers. That investigation is tracked separately in #729.
• Forced on-disk migration of existing records.

References

• Follow-up from #886, finding F8 and its versioning addendum.
• Related: #729 tracks whether telemetry eventually permits deleting legacy v1/v2 wrapping code; it does not address unknown future versions.