…tension

Remove all built-in S3 datastore code from the core binary and delegate
S3 storage entirely to the `@swamp/s3-datastore` extension. This
follows the same pattern as PR #736 which moved vault providers to
extensions.

## What changed

### Built-in S3 code removed
- Deleted 6 infrastructure files: `s3_client.ts`, `s3_lock.ts`,
  `s3_cache_sync.ts`, `s3_datastore_verifier.ts`, and their tests
- Removed `S3DatastoreConfig`, `S3ConnectionConfig` from the type system
- Removed `@aws-sdk/client-s3` from `deno.json` (no longer bundled)
- Removed all `config.type === "s3"` branches from `repo_context.ts`,
  `resolve_datastore.ts`, `setup.ts`, `sync.ts`, `status.ts`
- Removed `swamp datastore setup s3` CLI command

### Generic extension setup command added
- New `swamp datastore setup extension <type> --config '{...}'` command
  works with any extension datastore, not just S3
- Validates config against extension schema, verifies health via
  provider, migrates data via sync service, updates `.swamp.yaml`
- Supports legacy type names: `swamp datastore setup extension s3 ...`
  auto-remaps to `@swamp/s3-datastore`

### Backward compatibility preserved
- `type: s3` in `.swamp.yaml` auto-remaps to `@swamp/s3-datastore`
  with deprecation warning (from Phase 1+2 in PR #910)
- `SWAMP_DATASTORE=s3:bucket/prefix` env var format still works
- Extension auto-resolves on first use for logged-in users

### Docs and skills updated
- `design/datastores.md`: S3 now documented as extension, not built-in
- `README.md`: Updated setup examples to use extension command
- `.claude/skills/swamp-repo/SKILL.md`: Updated command reference

## Design choices

### Why the provider pattern is better than built-in
The old code created `S3Client` at 6+ call sites in `repo_context.ts`,
manually destructuring config fields each time. PR #917 found that
`endpoint` and `forcePathStyle` were silently dropped at several sites,
breaking S3-compatible stores (DigitalOcean Spaces, MinIO). The
extension's provider pattern stores config once at construction and
passes it through everywhere — structurally immune to this class of bug.

### Sync behavioral differences
The built-in S3 path used `pullAll()`/`pushAll()` for sync operations.
The extension path uses `pullChanged()`/`pushChanged()` via the
`DatastoreSyncService` interface. The "changed" variants are better for
normal use (only transfer what's needed). For empty caches, they're
equivalent since everything is "changed". The built-in also had
`pullChangedForModel()` for per-model scoped pulls — an optimization
not available through the generic interface, acceptable trade-off for
now.

### `datastore status` no longer shows S3-specific fields
Bucket, prefix, region, endpoint are no longer displayed in
`swamp datastore status`. The generic extension interface doesn't
expose backend-specific details. The health check still works via the
provider's `createVerifier()`.

### Known limitation: offline + legacy S3 config
If a user has `type: s3` in `.swamp.yaml`, is offline, and the extension
isn't cached, `resolveDatastoreConfig` throws before any command runs.
The error message is clear ("Install it with: swamp extension pull
@swamp/s3-datastore"). This is an edge case — the extension is cached
after first use.

## Test plan

- [x] `deno check` — clean
- [x] `deno lint` — 910 files, clean
- [x] `deno fmt` — 998 files, clean
- [x] `deno run test` — 3672 passed, 0 failed
- [x] `deno run compile` — binary compiles without `@aws-sdk/client-s3`
- [x] Manual test: compiled binary against real S3-backed repo, extension
      auto-resolved and command completed cleanly
- [ ] CI passes

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>