fix: support native wasm dependencies in vite ssr

[dvd233]

Summary

• keep remote Deno-native Wasm modules in the server runtime graph instead of passing their bytes through Vite's JavaScript import analysis
• externalize generated JavaScript wrappers that statically import .wasm, preserving the wrapper and binary under the same Deno module graph
• add dev and production regressions using the reported jsr:@deno/doc@0.202.1 dependency and execute its Wasm-backed doc() API

Why

Vite's Wasm support expects its own asset/import conventions, such as ?init, while generated Deno packages use native ESM Wasm imports. Treating the binary as a regular Vite module makes import analysis parse Wasm bytes as JavaScript. Adding *.wasm to assetsInclude would instead turn the import into a URL string, which does not satisfy the generated wrapper's module-namespace contract.

The server resolver now leaves those native Wasm edges to Deno, while browser and non-default module resolution remain unchanged.

Tests

• baseline exact fixture reproduced the deno_doc_wasm.wasm import-analysis failure
• deno test -A --cached-only packages/plugin-vite/tests/build_test.ts packages/plugin-vite/tests/dev_server_test.ts: 79 passed, 0 failed, 1 existing ignored test
• deno task check:types
• changed-file deno fmt --check, deno lint, and deno check
• frozen cached install for the new @deno/doc fixture
• git diff --check

Note: the repository-wide formatter reports pre-existing differences in www/static/docsearch.css and www/static/prism.css; this PR does not touch either generated/static file.

Fixes #3897