#2501 Orphaned data record survives a model type migration and is unreachable by data delete/versions/prune

When a model's type is changed in place (same model ID, e.g. via an extension re-index/rename) while keeping the same resource/data name, the old-type data record is left behind in the catalog and cannot be reached by any exposed command:

• swamp data query '<predicate over modelName/specName>' (raw catalog scan) DOES see both records — one tagged with the old modelType, one with the new — both isLatest: true, each with its own independent version counter.
• swamp data delete <model> <name>, --prefix, and --all all resolve the model to its CURRENT type first and only ever touch the current-type lineage. The old-type record is invisible to all three.
• swamp data versions <model> <name> shows only the current-type lineage's versions.
• swamp data get <model> <old-record-id> fails with "Data not found" — the record's own catalog ID isn't independently addressable via data get.
• swamp data prune only reclaims data whose owning MODEL DEFINITION no longer exists at all. Since the model ID here is still live (just retyped), prune does not consider the old-type record orphaned.
• There is no swamp model command to migrate/consolidate a model's data across a type change.

Net effect: the stale record is permanently stuck in the catalog with no CLI path to remove it, short of hand-editing .swamp/data/ on disk (which bypasses swamp entirely and isn't something users should have to do).

Why it matters: workflow asserts using data.latest(modelName, specName) fail with `Ambiguous data.latest() match: specName "" resolves to 2 data items (, )" — every run is marked Failed even when the fetch and report both succeeded, because the CEL matcher (unlike the CLI resolution) matches by (modelName, specName) without considering modelType, so it finds both records and can't disambiguate.

Repro:

1. Create a model of type A with a resource/data name "foo", run a method that writes it.
2. Change the model's type field to type B (same model ID), e.g. by re-pointing to a renamed/re-indexed extension.
3. Run a method on the same model that writes a resource also named "foo" (under type B).
4. swamp data query 'modelName == "<model>" && specName == "foo"' now returns 2 records for the same model.
5. Any workflow assert using data.latest("<model>", "foo") now errors with the ambiguous-match message, and none of data delete/data versions/data prune can remove the stale one.

Suggested fix: either (a) have data delete/data versions/data prune resolve by data ID or across all modelType tags for a given modelId rather than filtering to only the model's current type, or (b) expose an explicit way to target a specific data record by its catalog ID (e.g. swamp data delete --id <id>), or (c) have data.latest() prefer the record matching the model's current type when multiple specName matches exist for the same modelId, instead of erroring.