#220 workflow run search returns empty after S3 datastore setup, despite run YAMLs in datastore

Description

After switching a repo from filesystem to S3 datastore via swamp datastore setup extension @swamp/s3-datastore --config '{...}' --skip-migration, swamp workflow run search returns no results — even though the S3 bucket contains a populated workflow-runs/<workflow-id>/workflow-run-*.yaml tree from prior runs (executed by other contributors against the same shared bucket).

The --skip-migration path is currently the only supported route into this configuration on macOS because of swamp Lab #213 (deno TLS panic on migration), so this is the realistic onboarding flow for any new developer joining a project that's already on a shared S3 datastore.

swamp datastore status reports the S3 datastore as healthy. swamp datastore sync reports "already up to date" / "0 pulled, 0 pushed", yet the local cache .swamp/workflow-runs/ stays empty until the files are fetched manually with aws s3 sync. Even after the files are in the local cache, swamp workflow run search still returns empty results — so the search command appears to consult a separate index (similar to .swamp/data/_catalog.db) that is neither shipped via S3 nor rebuilt from the synced YAML files.

Steps to reproduce

1. Start with a repo whose shared S3 datastore already has run history (i.e. another contributor has executed workflows against it).
2. On a fresh clone, run:

   swamp datastore setup extension @swamp/s3-datastore \
     --config '{"bucket":"<bucket>","region":"<region>"}' \
     --skip-migration

3. swamp datastore status --json → reports @swamp/s3-datastore, healthy.
4. swamp workflow search --json → returns the workflow definitions from S3.
5. swamp workflow run search --limit 100 --json → returns {"query":"","results":[]}.
6. aws s3 ls s3://<bucket>/workflow-runs/ → shows per-workflow directories with workflow-run-*.yaml and .log files.
7. swamp datastore sync → reports already up to date / no changes.
8. Manually aws s3 sync s3://<bucket>/workflow-runs/ .swamp/workflow-runs/ → 20+ run files land locally.
9. Re-run swamp workflow run search --limit 100 --json → still {"query":"","results":[]}.
10. Parsing the local YAML files directly confirms the run history is well- formed (status, startedAt, workflowName all populated).

Expected behavior

swamp workflow run search should surface workflow runs that exist in the shared datastore. Either:

• swamp datastore sync should populate whatever local index workflow run search consults (mirroring how the s3-datastore extension already syncs data/, workflows-evaluated/, etc.), OR
• swamp workflow run search should fall back to scanning the workflow-runs/ directory directly when the index is empty / stale.

Affected components

• @swamp/s3-datastore extension's sync logic — appears to skip workflow-runs/ (the directory exists in S3 but isn't part of the sync manifest).
• swamp workflow run search — depends on a local index that the S3 datastore's sync flow doesn't seed for new contributors.

Fix approach (high-level)

Either include workflow-runs/ in the s3-datastore sync set so the local index can be rebuilt from synced YAMLs, or add an index-rebuild step to datastore setup and datastore sync that scans workflow-runs/ and indexes any runs not already present. A lazy rebuild on first workflow run search call (when the index is empty but YAML files exist) would also make the failure self-healing.

Environment

• swamp version: 20260421.213501.0-sha.0432a31a
• Datastore extension: @swamp/s3-datastore 2026.04.28.4
• OS: macOS (Darwin 23.1.0)
• Setup invoked with --skip-migration due to Lab #213.

Related issues

• #213 — Filesystem→S3 migration TLS panic (forces --skip-migration, which is the path that exposes this bug).
• #218 — S3 datastore stale-lock loop (different S3 sync issue).
• #201 — Catalog retains stale source-file entries (catalog/index consistency theme).