#524 swamp workflow validate emits misleading "Extension failed to load" warning when type resolves locally

Summary

swamp workflow validate repeatedly emits

extension·auto-resolve  Extension "@swamp/digitalocean" is already installed at
                        /…/.swamp/pulled-extensions/@swamp/digitalocean
                        but failed to load.
extension·auto-resolve  Local edits may be preventing it from registering —
                        inspect the source and fix errors.
extension·auto-resolve  To reset to the registry version and discard local
                        changes, run: swamp extension pull "@swamp/digitalocean"
                        --force

for every workflow step whose model type comes from an installed extension. The warning is misleading — the extension does load successfully via the local-bundle path that swamp model type describe, swamp model get, and actual method execution all use. Only the validator's auto-resolve fallback errors. The user is told to run --force even when nothing is actually broken.

Reproduction

Giga-swamp-like repo with @swamp/digitalocean and @swamp/kubernetes pulled:

1. swamp extension install — clean, no errors.
2. swamp extension pull @swamp/digitalocean --force.
3. swamp doctor extensions → 5 passed, 0 failed — OVERALL: PASS.
4. swamp model type describe @swamp/digitalocean/kubernetes-cluster --json → returns full schema and all methods (including locally-added ones).
5. swamp model get <any-cluster-model> --json → returns the model fine.
6. swamp workflow validate <workflow-referencing-that-type> → emits the auto-resolve error twice per affected step. Validation itself still reports PASSED.

Expected: no ERR line on the validate path when the type is loadable via the normal local-bundle path.

Actual: the error fires every workflow validate (and likely every workflow run too — haven't executed yet). Non-blocking, but produces a wall of noise that hides real failures.

Environment

• swamp 20260601.142529.0-sha.6885aa31
• Darwin 25.3.0 (macOS, arm64)
• @swamp/digitalocean 2026.05.29.1
• @swamp/kubernetes 2026.05.27.2
• Local extensions/models/*.ts overlays on @swamp/digitalocean/kubernetes-cluster (adds write_kubeconfig). The warning fires identically when those overlays are temporarily moved aside, so the issue is independent of local extensions.

Tried (none cleared the warning)

• swamp extension install
• swamp extension pull @swamp/digitalocean --force
• rm .swamp/_extension_catalog.db* and re-resolve
• swamp doctor extensions
• Removing local overlay extensions, re-running validate, restoring them

Hypothesis

The workflow validator's auto-resolve code path tries to fetch the type via the registry rather than reusing the already-loaded local bundle. The registry lookup surfaces a generic "but failed to load" error and tells the user to run --force, instead of falling through to the working local-load path (or recognizing that the type is already resolved and skipping the lookup entirely).

A possible quick win: when extension·auto-resolve finds an extension already installed locally and swamp model type describe <type> succeeds, suppress the warning and the "run --force" suggestion. Long-term, the auto-resolver should share the same load path as model type describe.

Impact

Cosmetic but high-noise. A multi-step deploy workflow (e.g. our 8-step deploy-swamp-club-k8s) emits 16+ ERR lines per validate, drowning real diagnostics. Also undermines confidence — users (and AI agents) reasonably read "failed to load" as a real failure and chase fixes (pull --force, catalog delete, doctor) that don't help.