Recommend or manage lockfile strategy for extension model npm dependencies

Problem

When extension models use Deno-style npm: import specifiers (e.g. import { z } from "npm:zod@4"), the repo's deno.lock does not include the npm dependency resolution. Agentic code reviewers (e.g. pi-judge) flag this as a reproducibility gap and suggest regenerating the lockfile — but the fix can't be cleanly applied.

Current behavior

1. Extension models import npm packages via npm:zod@4 specifiers
2. Swamp resolves these internally via its own Deno runtime
3. The repo's deno.lock has no entry for these npm dependencies
4. Running deno cache to fix it fails without a deno.json, or requires --node-modules-dir=auto which also resolves unrelated package.json dependencies (e.g. @anthropic-ai/claude-code and all its optional deps), bloating the lockfile

Proposed solution

One of:

• Swamp manages a lockfile for extension model dependencies (e.g. during swamp extension push or swamp repo index)
• Recommend a deno.json pattern scoped to extensions/ with explicit imports, so users can run deno cache cleanly
• Document that deno.lock is not expected to cover swamp model deps, so agentic reviewers and humans know to ignore this

Alternatives considered

• Adding npm deps to package.json — wrong tool for Deno-style imports
• Creating a root deno.json — pulls in unrelated deps from package.json in the same directory

Additional context

Discovered during PR review of swamp extension models in https://github.com/hivemq/hivemq-terraform-harvester/pull/69. An automated multi-model reviewer flagged the missing npm:zod@4 resolution in deno.lock as a medium-severity reproducibility issue.