Fix wizer preinit file access issue

[vigoo]

Resolves #91

Root cause: During wizer pre-init, the wasm-rquickjs runtime evaluates the bundled user JS. When that bundle contains code like exa-js's node-fetch dep — which has try { require('encoding') } catch {} at module-eval time — the JS require shim walks node_modules via fs.readFileSync → Rust fs_open → std::fs::OpenOptions::open. The first such call triggers wasi-libc's lazy preopen-cache population against the empty wizer host environment (which provides no preopens), and the broken empty-cache state gets snapshotted by Wizer. After restore, std::fs::* operations fail with ENOENT scandir ‘/' even though wasmtime has provided real preopens.

Fix:

New WIZER_ACTIVE: AtomicBool static + is_wizer_active() helper, set to true for the duration of wizer_initialize().
Path-based fs ops (fs_open, fs_stat, fs_lstat, fs_readdir, fs_realpath, fs_readlink, fs_access) short-circuit with a synthetic ENOENT wizer_enoent_obj when the flag is set, never invoking std::fs::* and so never poisoning wasi-libc's preopen cache.