#3011 readModelData silently drops data written before a model instance rename

Description

context.readModelData(modelName, specName) returns only records whose stored modelName tag equals the name passed. That tag is stamped when a record is written, and it is not updated when the model instance is renamed. After a rename (editing the definition's name; the model ID does not change), every record written before the rename is silently excluded — although the data still belongs to the same model ID, and swamp data list <new-name> shows it.

The two code paths in DataAccessService.readModelData (src/domain/data/data_access_service.ts) disagree:

• Catalog path (dataQueryService present — the normal case): queries the tags with modelName == "<name>" && specName == "<spec>". Pre-rename records are excluded.
• Fallback path (no catalog): resolves the name to the model ID and reads everything under it (plus orphan recovery for previous IDs). Pre-rename records are included.

So the same call returns different data depending on an internal detail.

Steps to reproduce

1. Create a model instance old-name and run a method that writes a resource of spec foo.
2. Rename the instance: edit the definition YAML name: old-name → name: new-name (same id). swamp model validate new-name passes.
3. Run a method again so it writes another foo record (now tagged modelName: new-name).
4. In a method of new-name, call context.readModelData([HOST-1], "foo").

Expected: both foo records (same model ID). Actual: only the record written after the rename. swamp data list new-name lists both, and swamp data get new-name <older-record> --json shows tags.modelName: "old-name".

Impact

Silent data loss from the method's point of view. In our case, an extension's snapshot/image retention records that were written before a rename became invisible to its prune and rollback methods, so those snapshots would never have been pruned. Nothing errors or warns.

Suggested fix (high level)

Make the catalog path resolve the name to the model ID and match on the model ID (with the same orphan-recovery scope as the fallback path), or update the modelName tag on existing data when a definition is renamed. At minimum, document that readModelData matches the name recorded at write time.

Workaround: read a model's own data by ID with context.dataRepository.findAllForModel(context.modelType, context.modelId).

Environment

• swamp 20261003.192630.0-sha.bed0772a (latest; the catalog-path query is unchanged from 20260904.171927.0)
• macOS, filesystem datastore with the data catalog present