Reject Windows drive module paths safely across hosts

Goal

Port Bun's plugin namespace behavior for Windows drive paths and make the failure path safe on non-Windows hosts.

Root cause

• PluginRunner.extractNamespace() only recognized drive paths on Windows, so a literal C:\\... module key could be mistaken for plugin namespace C on macOS/Linux.
• Once the namespace ambiguity was removed, the POSIX resolver treated normalized C:/... as a package path and reached an internal absolute-directory assertion instead of reporting an ordinary unresolved import.
• The existing copied Bun regression had previously passed for the wrong reason before native resolver activation; the activated path exposed both defects.

Acceptance criteria

• Drive-rooted module keys are never interpreted as one-letter plugin namespaces, regardless of host OS.
• All ASCII drive letters, including A/a/Z/z, are handled.
• Foreign Windows drive paths reject as unresolved on POSIX instead of panicking or printing an internal stack.
• js/bun/plugin/plugin-namespace-drive-letter.test.ts passes natively.
• Full home_test gate passes.
• Land the fix on main and link the commit.

Evidence

Focused copied Bun corpus after the fix:

tests passed: 1
tests failed: 0
tests unsupported: 0
tests todo: 0

Related stdin tranche: #187 Umbrella: #66

Landed

• 5bd10420f fix(runtime): reject foreign drive module paths

Landed on main in 5bd10420f.

Final verification:

• copied js/bun/plugin/plugin-namespace-drive-letter.test.ts: 1 passed / 0 failed / 0 unsupported / 0 TODO
• foreign C:/... imports now reject normally on POSIX instead of reaching dirInfoCached()'s absolute-path assertion and dumping an internal stack
• drive-letter detection is host-independent and includes boundary letters A/a/Z/z
• full zig build test -Dfilter=home_test --summary failures: exit 0
• Zig format and git diff --check: clean

This was a latent post-resolver-activation bug uncovered while closing #187.