#287 Repo-level version gating: minSwampVersion high-water mark for team consistency

Problem

When a team shares a swamp datastore, individual members can be on different swamp versions. If one member auto-updates (via #227) or manually runs swamp update, they may write data with a newer version while teammates remain on older versions. This can lead to subtle compatibility issues with no warning.

Proposed solution

Add an opt-in repo-level version gating mechanism:

1. Add an optional minSwampVersion field to the existing RepoMarkerData interface (persisted in .swamp.yaml). Missing field defaults to no gating — safe for existing repos, no migration required.

2. On write operations, stamp the CLI version as the high-water mark. When a user runs a write command (model method run, workflow run, data writes) and the CLI version is newer than minSwampVersion, update the field in .swamp.yaml.

3. On write operations, gate teammates below the high-water mark. When a user attempts a write and their CLI version is below minSwampVersion:

   • In TTY mode: prompt to upgrade ("Your version is below the repo minimum. Run swamp update to upgrade.")
   • In non-TTY/CI: emit a blocking error with swamp update instructions

4. Read operations are never gated. Commands using requireInitializedRepoReadOnly() (model get, data get, output search, etc.) bypass the gate entirely so nobody gets locked out of inspecting data.

5. Enable via swamp config set repo.versionGating enabled.

Implementation notes from the approved plan

• Reuse the existing SwampVersion value object from src/domain/repo/swamp_version.ts for CalVer comparison (compareTo, isNewerThan)
• Hook into the existing read-vs-write split: commands using requireInitializedRepoReadOnly() are reads; all others are writes
• Wire the pre-execution check into src/cli/repo_context.ts (the non-read-only repo context acquisition path)
• The high-water mark ratchet only goes up — document manual .swamp.yaml editing as the rollback escape hatch
• This is independent of background autoupdate (#227) but complementary: autoupdate advances one person, gating pulls the rest forward on writes

Key design decisions

• Opt-in at repo level — teams that do not care about version consistency never see this
• Gate only on writes — read-only commands always work regardless of version
• CalVer lexicographic comparison — swamp versions (YYYYMMDD.HHMMSS.patch-sha.hash) sort correctly as strings
• No migration needed — missing minSwampVersion in existing .swamp.yaml files means no gating

Relationship to autoupdate

The two features are independent opt-ins:

• Solo user with autoupdate, no gating: binary stays fresh, no team impact
• Team with gating, no autoupdate: everyone runs swamp update manually when gated
• Both enabled: one person's autoupdate naturally pulls the team forward via the gate

Files likely affected

• src/domain/repo/version_gate.ts (new) — VersionGate domain concept
• src/infrastructure/persistence/repo_marker_repository.ts — add minSwampVersion to RepoMarkerData
• src/cli/repo_context.ts — pre-execution check on write commands
• design/update.md (new) — document the architecture
• design/repo.md — reference minSwampVersion field