#241 performance degrades significantly with large SQLite catalog

Observation

Workflow execution rate drops significantly as the .swamp/data/_catalog.db grows:

At 2.2GB total .swamp/ size with ~106MB catalog database, workflow runs take 3-4x longer than when the repo was fresh.

Root Cause Hypothesis

Each workflow run performs many SQLite reads/writes to the catalog (one per step output, plus report generation). With a large catalog and concurrent access (5 parallel workflow runs), WAL-mode SQLite contention becomes the bottleneck.

Suggestions

1. WAL checkpoint on gc — swamp data gc could VACUUM the catalog after purging old versions
2. Catalog partitioning — separate catalog per model or per time window
3. Incremental indexing — ensure catalog queries use indexed columns (modelName, tags, createdAt)
4. Connection pooling — if concurrent runs each open separate connections, pool them
5. Periodic auto-compact — offer swamp datastore compact that checkpoints WAL and rebuilds indexes

Impact

Long-running automation repos (CI/CD, monitoring loops) will hit this. A repo doing 100+ workflow runs per day will see meaningful slowdown within a week.

Environment

• swamp version: 20260504.233645.0-sha.430c1535
• Repo: ~4,500+ workflow runs, 2.2GB .swamp directory, 106MB catalog.db + 40MB WAL