bun pm trust / bun pm untrusted throw EUNKNOWN on Windows when a node_modules path exceeds MAX_PATH (260 chars)

### What version of Bun is running? 1.3.14+0d9b296a ### What platform is your computer? Microsoft Windows NT 10.0.19045.0 x86_64 unknown ### What steps can reproduce the bug? In a monorepo whose `node_modules` contains at least one installed package whose full absolute install path exceeds 260 characters (e.g. a deeply-scoped/versioned package under `node_modules/.bun/...`), run either: ``` bun pm trust bun pm untrusted ``` Both commands scan installed packages for pending/untrusted lifecycle scripts. In this repo, one such path is: ``` C:\Users\Alex\Documents\Github\myrepo\node_modules\.bun\@babel+plugin-bugfix-safari-id-destructuring-collision-in-function-expression@7.29.7+a9511e88299503d5\node_modules\@babel\plugin-bugfix-safari-id-destructuring-collision-in-function-expression\lib\index.js.map ``` — 265 characters, over the classic Win32 `MAX_PATH` (260). Windows long-path support is enabled at the OS level (`HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1`), and other bun subsystems handle long paths fine (per #21244), but this particular scan still fails. ### What is the expected behavior? `bun pm trust <names>` / `bun pm trust --all` and `bun pm untrusted` should either list the untrusted packages/dependencies with pending lifecycle scripts, or print a normal, mapped error. ### What do you see instead? ``` $ bun pm untrusted bun pm untrusted v1.3.14 (0d9b296a) error: An internal error occurred (EUNKNOWN) ``` Reproduces identically: - From the repo root and from a workspace subdirectory (`apps/app`) — same monorepo, same node_modules. - With `bun --verbose pm untrusted` — no additional detail is printed. - `bun pm trust` (no args) fails differently first, with `error: expected package names(s) or --all`, which is correct/expected; the bug is in the underlying scan hit by `--all` or by `pm untrusted`. ### Additional information `EUNKNOWN` in bun generally means an OS/Win32 error code came back that bun's errno-mapping layer doesn't recognize — consistent with a raw `CreateFileW`/`NtCreateFile`-style call being made without the `\\?\` long-path prefix on a path >260 chars, similar to the pattern already reported in: - #8246 — original Windows long-path report (closed, precursor to #21244) - #21244 — added Windows long-path support (merged 2025-07-21) — evidently not applied to the `pm trust`/`pm untrusted` package scanner - #33336 (open) — `bun:sqlite` VFS skips the `\\?\` prefix on `CreateFileW`, same inconsistency in a different subsystem - #32220 (open) — assertion failure in `openDirAtWindowsNtPath`, the NT-path directory-open codepath likely shared by this scanner Happy to provide a minimal repro repository if useful — the trigger seems to just be any installed package whose full path exceeds 260 characters, which is common in JS monorepos with deeply nested/scoped transitive deps.