…on (#910)

## Summary

- Add auto-resolution infrastructure for datastore extensions (mirrors
the vault pattern from #736)
- Add name remapping: `type: s3` in `.swamp.yaml` →
`@swamp/s3-datastore` extension
- Backward compatible — built-in S3 code is still present as a fallback

This is the first step toward moving the S3 datastore to the
`@swamp/s3-datastore` extension package (published as v2026.03.28.1 in
the [swamp-extensions](https://github.com/systeminit/swamp-extensions)
repo). A follow-up PR will remove the built-in S3 code once this is
validated.

### Phase 1: Auto-resolution infrastructure
- `resolveDatastoreType()` helper in `extension_auto_resolver.ts`
- `hotLoadDatastores()` in `ExtensionInstallerPort` and auto-resolver
adapter
- Datastores are now hot-loaded alongside models and vaults after
extension install

### Phase 2: Name remapping
- `RENAMED_DATASTORE_TYPES` map: `"s3" → "@swamp/s3-datastore"`
- `resolveDatastoreConfig` and `parseDatastoreEnvVar` are now async
- Old `type: s3` configs auto-resolve the extension, with deprecation
warning
- Falls back to built-in S3 if extension unavailable

## User impact

- **No breaking changes** — existing `type: s3` configs work as before
- Deprecation warning logged when old `s3` type name is used
- First use auto-installs extension (~5s one-time); subsequent runs use
cache
- Requires `@swamp/s3-datastore` extension published to registry (done:
v2026.03.28.1)

## Test plan

- [x] Compiled binary, tested against real S3-backed repository
- [x] First run: extension auto-resolved, downloaded, bundled, cached
- [x] Second run: loaded from cache, no registry call, completed cleanly
- [x] All unit tests pass (38 tests across modified files)
- [ ] CI passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

…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]>