#3760 v3: datastore config migrate skips every workflow that has run (name-committed), and they are then "not found" (found by #3756)

Background

swamp's datastore rework (tracking: swamp-club#2865) has finished solo mode. On a v3 datastore, managedConfig keeps definitions, workflows and vault configs in the datastore's config tier. swamp datastore config migrate turns it on by committing the repo's existing definitions into that tier (planConfigAdoption, src/infrastructure/datastore_v3/v3_config_adoption.ts, swamp-club#3300).

Dogfooding solo v3 (swamp-club#3756) found that the migrate loses every workflow that has ever run.

What happened

On a v3 datastore, swamp datastore config migrate turns managedConfig on but skips every workflow that has ever run, as name-committed. After it, swamp workflow run <name> fails with Workflow not found for each of them.

Found while dogfooding solo v3 (swamp-club#3756), on a binary built from main at ea2a36f51, and reproduced on the released 20261021.050521.0-sha.bfde0792.

Steps to reproduce

1. swamp init --tool none in an empty directory, then swamp datastore setup filesystem --path <dir> --format 3.
2. swamp model create command/shell sh1; swamp workflow create wfa, and give it one step that runs sh1 execute with run: echo hi.
3. swamp workflow run wfa (succeeds).
4. swamp datastore config migrate --json: copiedWorkflows is false, and skipped holds {kind: workflow, name: wfa, reason: name-committed}.
5. swamp workflow run wfa: Workflow not found: wfa.

Without step 3 the workflow is copied and keeps working. On a v2 datastore the same steps work.

In the dogfood repos (v3 on S3 and on GCS, 30 workflows each, all of them run before the migrate), the migrate skipped 30 of 30 workflows, and 10 of 10 workflow runs after it failed.

Expected

The migrate commits each workflow definition into the config tier, as it does for one that has never run, and the workflow keeps running.

Likely cause

A workflow run stages its evaluated workflow into the config partition {kind: config, definitionKind: workflow, name} (ConfigChanges, src/domain/datastore_v3/repository_changes.ts). planConfigAdoption in src/infrastructure/datastore_v3/v3_config_adoption.ts asks partitionHasCommits(changes.partition), which is true, so it records name-committed and skips a definition that was never committed.

What to do

1. Decide "already committed" per record, not per partition. Skip a workflow only when the definition's own key is committed. A partition holding only an evaluated workflow (or anything else a run stages) doesn't mean the definition is there. Apply the same rule to every kind adoption handles: models, vault configs, and anything else that shares a partition with what runs stage.
2. Repos already hit by this: a second datastore config migrate must pick up the workflows the first one skipped, if their source files are still where adoption reads them. If they're gone (moved or deleted by the first migrate), say how a user gets them back, and make the skip impossible to miss: a warning naming each skipped workflow, not only a skipped entry in --json.
3. Docs: the managedConfig section of design/enablers/datastores.md, and the swamp skill's datastore reference, if they describe the skip reasons.

Tests

Each must fail on main first.

• v3: create a workflow, run it, migrate, and the workflow is copied (not skipped) and workflow run works afterwards. The same for a model whose method has run, and for a vault config.
• A repo already migrated by the buggy version: a second migrate copies the skipped workflows (or the documented recovery works).
• v2 is unchanged.
• swamp-uat passes unchanged. The managedConfig rows of the v3 datastore suites probably never ran a workflow before migrating; if a test can be added there, propose it as a swamp-uat issue.

Severity: high. Anyone turning on managedConfig in a v3 repo that has run a workflow loses those workflows. The released binary does the same. It blocks announcing v3 on buckets (swamp-club#3756).