#741 telemetry stats fatally fails to load an installed datastore extension (auto-resolve path); all other commands load it fine

Summary

swamp telemetry stats cannot load the repo's configured custom datastore extension and aborts fatally with Unknown datastore type "<type>" in .swamp.yaml. Available types: filesystem.

Every other command tested — model list, data list, report list, model search — loads the same on-disk extension correctly and reads from the datastore (e.g. model list returns 500+ lines). So the extension and .swamp.yaml config are healthy; only telemetry stats is broken.

The failing path routes datastore initialization through extension·auto-resolve, which wrongly claims the type is "not found locally" even though it is installed and loads fine for every other command — then emits one of several different, misleading errors and fatally aborts.

Environment

• swamp 20260621.225920.0-sha.b2d542b2 (confirmed up to date via swamp update --check)
• macOS (darwin 23.6.0)
• Datastore: a pulled third-party datastore extension, freshly re-pulled today; deno check on its entry module passes; source files are pristine registry copies with no local edits.
• .swamp.yaml datastore block (values redacted):

datastore:
  type: '<collective>/<datastore-extension>'
  config:
    uri: 'mongodb://<host>:27017/?replicaSet=rs0&authSource=admin'
    username: <redacted>
    passwordEnv: MONGO_PASSWORD
    database: <redacted>
    namespace: <redacted>

Steps to reproduce

In a repo whose .swamp.yaml datastore.type is a pulled (non-filesystem) datastore extension:

1. swamp model list → works, returns hundreds of lines from the datastore
2. swamp data list → works
3. swamp report list → works
4. swamp telemetry stats → FATAL (reproduces on every run)

Actual

telemetry stats fails every time while the data-plane commands succeed against the same datastore. At least three distinct failure variants were observed across consecutive identical invocations:

Variant A (after an ~15s registry search):

INF extension·auto-resolve Extension type "<type>" not found locally, searching registry...
ERR extension·auto-resolve Auto-resolution failed for type "<type>": no matching extension found in registry.
ERR extension·auto-resolve Install manually with: swamp extension pull <extension-name>
FTL error Error: 'Unknown datastore type "<type>" in .swamp.yaml. Available types: filesystem'

Variant B (most runs):

INF extension·auto-resolve Extension type "<type>" not found locally, searching registry...
ERR extension·auto-resolve Extension "<type>" is already installed at "<repo>/.swamp/pulled-extensions/<type>" but failed to load.
ERR extension·auto-resolve Local edits may be preventing it from registering — inspect the source and fix errors.
ERR extension·auto-resolve To reset to the registry version and discard local changes, run: swamp extension pull "<type>" --force
FTL error Error: 'Unknown datastore type "<type>" in .swamp.yaml. Available types: filesystem'

(The extension is in the registry — swamp extension info <type> returns full metadata, verified repo — so Variant A's "no matching extension found in registry" is also incorrect.)

Expected

telemetry stats should load the configured datastore exactly the way model/data/report commands do — from the locally pulled extension — and never route through registry auto-resolution. At minimum it must not fatally abort on a datastore that every other command loads successfully in the same repo, same session.

Secondary defects in this code path

1. Misleading fatal message. Unknown datastore type ... Available types: filesystem implies the type is unconfigured/unknown, when it is configured and demonstrably loadable; the real failure is in the loader, not the config.
2. False "local edits" accusation. "Local edits may be preventing it from registering" fires on a pristine, freshly re-pulled extension (deno check passes). The suggested fix (swamp extension pull --force) is a dead end and misleads users into discarding a correct install.
3. Underlying error swallowed even at SWAMP_LOG=trace. Trace output adds nothing beyond the generic "failed to load," so the real registration exception cannot be diagnosed from logs.
4. Non-determinism. Different error variants on consecutive identical invocations indicate a race or inconsistent fallback within the auto-resolve path.