First-class jsr: specifier support in extension bundler

Problem

The extension bundler explicitly skips jsr: specifiers. Only npm: specifiers are first-class; https:// imports are also unsupported. Extension authors on a Deno-native toolchain must publish shared helpers to npm to get any form of code reuse, which is a detour.

Where it's skipped: src/domain/models/bundle.ts — a comment around line 189 reads "Skip jsr: prefixed imports". The bundler does not resolve or inline them.

Today's allowlist:

• npm: — inlined at bundle time (zod is the sole externalization exception).
• node: — built-ins, passed through.
• Bare specifiers — require a deno.json import map.
• jsr: — skipped.
• https:// — not supported.

Proposed solution

Resolve and inline jsr: specifiers the same way npm: specifiers are handled today. Likely implementation path:

• Let deno bundle / esbuild handle JSR resolution natively (Deno already supports jsr: in its bundler output).
• Update the bundle driver to stop filtering jsr: out of the import graph.
• Extend any import-validation code to treat jsr: as a permitted specifier.
• Confirm JSR packages are inlined (not externalized) so extension bundles remain self-contained, matching the existing npm behavior.

Smaller scope than the companion exports: manifest field feature request — no manifest changes, purely bundler work. Lets extension authors publish shared helpers to JSR (the Deno-native registry) and import them directly across extensions.

Alternatives considered

• Keep publishing helpers to npm. Works today but is friction for a Deno-native ecosystem.
• exports: manifest field (filed as a separate issue). Larger scope; enables sharing code between installed extensions without going through any registry. Complementary, not a substitute.