#883 Extension skill should explicitly prohibit bare 'zod' imports (scorer sandbox fails)

Problem

The extension development skill/docs explain that swamp's bundler excludes zod (it's provided at runtime), but they do NOT warn that bare from "zod" imports will fail the swamp.club scorer. The scorer runs deno doc --lint in a sandbox without the extension's deno.json import map, so bare specifiers can't resolve.

This creates a trap: bare "zod" works locally (via import map), works at runtime (bundler provides it), but fails scoring. The fix is always the same — change to from "npm:zod@X.Y.Z" — but nothing in the skill prevents the mistake.

Evidence of Repeated Failures

Six extensions in webframp/swamp-extensions hit this exact issue over a 2-month span:

PR #67 ("enforce extension compliance standards") attempted to fix this across all extensions in May, but new extensions (cloudflare, twitch) reintroduced the problem because the underlying guidance doesn't prevent it.

Root Cause

Three execution contexts resolve imports differently:

1. Local Deno — uses deno.json import map → bare "zod" works
2. Swamp bundler — excludes zod, provides at runtime → bare "zod" works
3. Scorer sandbox — runs deno doc --lint without import map → bare "zod" FAILS

The skill only explains context #2. Agents and humans reasonably infer "zod is special, use bare import" without knowing about context #3.

Proposed Solution

Add an explicit rule to the extension development skill/docs:

Always use explicit npm:zod@<version> in import statements — never bare "zod". The swamp-club scorer runs deno doc --lint without your deno.json import map. Bare specifiers resolve locally but fail in the scorer's sandbox. Do not add zod to the deno.json imports map either — use the inline npm: specifier directly.

This should appear in the imports/dependencies section of the extension authoring guide, ideally with the scorer explanation so the why is clear and agents don't try to "optimize" it away.