fix: use runtime filesystem for file:// requests

[fraidev]

Closes #640.

Problem

fetch() calls against file:// URLs (e.g. those resolved from npm: specifiers via import.meta.resolve) were reading from the host filesystem directly via tokio::fs,
bypassing the runtime's configured deno_fs. This caused them to fail in sandboxed environments where the runtime FS differs from the host FS.

The root cause: the startup snapshot bakes in a default FsFetchHandler backed by tokio::fs, and nothing was overriding it post-snapshot with an implementation that uses
OpState's FileSystemRc.

Solution

Mirrors the fix from denoland/deno#31814:

• Override the handler at runtime init — immediately after JsRuntime::new, swap deno_fetch::Options::file_fetch_handler for an FsFetchHandler that reads from OpState's
  FileSystemRc.
• Update the vendored FsFetchHandler — replace the tokio::fs + streaming path with fs.read_file_async(...), sourcing the FS from OpState instead of the host.