#3643 v3 on S3/GCS: setup on a prefix holding only swamp's format-3 marker fails with "this swamp release can't open" format 3 (found by swamp-uat#715)

Background

swamp is reworking its datastore layer (tracking: swamp-club#2865). swamp datastore setup extension … --format 3 (swamp-club#3534) first checks that the bucket prefix is a new, empty target: inspectV3BucketTarget in src/infrastructure/datastore_v3/v3_bucket_setup.ts. A prefix holding only swamp's format-3 marker counts as resumable: a setup that stopped after writing the marker, which a re-run completes. Found by swamp-uat#715.

The bug

Setup on a prefix that holds only a format-3 marker fails, and says the swamp release can't open format 3.

mkdir a && cd a && swamp init
swamp datastore setup extension @swamp/s3-datastore --format 3 --config "$CFG"
# repo A never writes, so the prefix holds only _control/datastore-format

mkdir ../b && cd ../b && swamp init
swamp datastore setup extension @swamp/s3-datastore --format 3 --config "$CFG" --json

Actual:

A v3 datastore needs a new, empty bucket prefix, but it could not be inspected (This datastore uses format 3 (written by swamp 20261019.165428.0-sha.2ffcdd66), which this swamp release can't open. Upgrade swamp to the latest release (swamp update). Nothing was synced.). Migrating an existing datastore to v3 is not supported yet. Nothing was changed.

The same swamp version wrote the marker, so "can't open … upgrade swamp" is wrong, and upgrading doesn't help. A re-run of A's own interrupted setup would hit the same thing, which makes the resumable path dead code.

Why: after it finds the marker, inspectV3BucketTarget still probes for v2 data with holdsV2RootData, through the extension's v2 sync service. Since swamp-club#3549 that service refuses any prefix whose marker says format 3 (datastore_format_unsupported, the "can't open … Nothing was synced" text), so the probe throws and the catch reports "could not be inspected".

What to do

1. When the prefix holds a valid format-3 marker, skip the v2-data probes. That's listNamespaces if it goes through the sync service, and holdsV2RootData. Setup ran those checks before it wrote the marker, and a compliant swamp never writes v2 data beside a v3 marker. Keep the other checks: no control-plane records, no chunks. Then complete the setup as resumable, as the code intends.
2. Another repo completing a marker-only prefix is allowed: the datastore is empty (no commits, no chunks, no records), so it's the same as a new prefix. Say so in the code comment and in datastores.md.
3. Never surface the extension's "can't open format N" text from setup's inspection. If a probe still fails for another reason, the message should say what couldn't be read, without the upgrade advice.

Tests

Each must fail on main first.

• In-process, on the in-memory remote or an emulator:
  • a prefix with only a format-3 marker: setup from the same repo completes;
  • setup from another repo completes too;
  • a marker plus a control-plane record is still refused ("already holds records"), as today;
  • a marker plus v2 index data planted directly is still refused. Plant it without the marker's guard, and check what the refusal says.
• swamp-uat passes unchanged. swamp-uat#715 leaves this case out until it's fixed, and can add it after.

Severity: medium. A wrong diagnosis with wrong advice, and an interrupted v3 bucket setup can't be completed.