#3567 Enforce the minimum S3/GCS extension version for v3 bucket datastores from the lockfile

Problem

A v3 datastore on S3 or GCS (swamp-club#3534) needs @swamp/s3-datastore / @swamp/gcs-datastore 2026.10.16.5 or later: the first release whose v2 file sync refuses a format-3 bucket (swamp-club#3549). swamp names that version in setup's refusal (V3_BUCKET_MIN_EXTENSION_VERSION in src/domain/datastore/v3_hosting.ts) and the docs say to pull the latest extension first, but nothing checks the version in the repo's lockfile.

The extension's refusal is the last guard in one case: a clone whose .swamp.yaml predates the format: 3 commit (it has no format), on a bucket whose marker read fails transiently. The format guard then keeps v2's behaviour (one capped read, open as v2), so that clone runs v2 sync against the v3 prefix. With an extension pinned below 2026.10.16.5 nothing stops it. Raised by the CI adversarial review on swamp-club/swamp#3180 (MEDIUM); agreed as a follow-up in #3534's architecture review.

Fix

Enforce the minimum version from the lockfile:

• datastore setup extension … --format 3 refuses when the locked extension version is below the minimum, naming swamp extension update <type>;
• opening a format-3 bucket datastore refuses the same way, so a teammate on an old pin cannot write;
• keep .swamp.yaml configs with no format on v2 (offline v2 reads must keep working, as swamp-uat's offline_test.ts checks).

Alternative raised by the review: apply the strict marker re-read to every config whose provider has the five v3 capabilities, not only overrides. That would break offline reads of v2 repos on current extensions, so the lockfile check is the preferred fix.