workflow validate can silently overwrite local edits to pulled extensions via force-pull in auto-resolver

Problem

Running swamp workflow validate can silently re-pull an extension from swamp.club and overwrite a user's local edits to the pulled extension directory, with no warning and no conflict prompt.

This happens because the auto-resolver's installer adapter hardcodes force: true when installing an extension it needs to resolve. If the local copy of an extension ends up not registered in the in-memory registry — for example because a manifest edit made it fail to index via registerLazyFromCatalog, or because a referenced type isn't present in the locally-indexed version — the resolver path is taken and the installer overwrites the pulled directory without asking.

A command the user reasonably expects to be read-only (validate) can therefore destroy local work.

Steps to reproduce

1. Pull an extension from swamp.club (e.g. @some/ext).
2. Edit a file inside the pulled extension directory (e.g. introduce a manifest issue, or modify a method).
3. Write or edit a workflow that references a model type from @some/ext.
4. Run swamp workflow validate.
5. If the local edits prevent the type from being registered as a lazy entry, the auto-resolver falls through to installExtension with force: true and overwrites the pulled directory. Local edits are gone. No prompt, no warning.

Scope of affected code

• src/cli/auto_resolver_adapters.ts — installer adapter hardcodes force: true with no distinction between "first-time install" and "extension already exists on disk."
• src/domain/extensions/extension_auto_resolver.ts — resolveModelType / installAndLoad calls the installer without checking whether the extension already exists locally, regardless of whether the user has modified it.
• src/domain/models/user_model_loader.ts — registerLazyFromCatalog flow determines whether a local extension is visible to the registry; silent skip paths here are what cause the fall-through.
• src/libswamp/extensions/pull.ts — respects force without considering whether the target directory has local modifications.

Suggested fix direction

• The auto-resolver should not invoke the installer with force: true unconditionally. At minimum, it should check whether the extension is already present on disk and refuse to overwrite without explicit user opt-in.
• Consider a "local modification" marker: if the pulled extension directory has been modified since install (e.g. checksum mismatch against the lockfile), workflow validate should surface a clear error rather than silently clobbering.
• Validation (and other read-intent commands) should probably not be allowed to pass force: true into the installer at all. A separate "auto-install missing dependencies on validate" behavior could stay, but overwriting existing extensions should require extension pull --force run deliberately.
• Related adjacent concern: hotLoadModels in the installer adapter only reloads from the pulled models dir and not from .swamp-sources.yaml source dirs, so after an auto-pull a local source override can end up shadowed at runtime. Worth addressing in the same pass.

Impact

Silent data loss of local WIP when developing or debugging extensions. Particularly painful because the triggering command (workflow validate) reads as a safe, side-effect-free operation.