fs: compiled `fs/promises` — real thread-pool backgrounding

[nickna]

Part of #968.

Problem

Compiled fs/promises is fake-async. Each method (FsReadFileAsync, FsWriteFileAsync, …) calls the corresponding sync implementation and wraps the result in Task.FromResult (see RuntimeEmitter.FsAsync.cs, BeginFsAsyncTryCatch → sync call → Task.FromResult; errors → Task.FromException). The returned promise is already-completed, so:

• the I/O runs synchronously on the calling thread — no overlap with other work;
• it diverges from the interpreter, which runs genuine Task.Run background I/O and resumes via the event loop.

Scope

• Replace the sync-then-FromResult shape with real backgrounding: run the op on the thread pool (Task.Run / the async BCL APIs File.ReadAllTextAsync etc.), return the in-flight Task, and resume continuations through $EventLoop with proper Ref/Unref so the loop stays alive until the op drains.
• Keep error mapping to Node shape (err.code).
• Align with the callback-async work (sibling child) so both share one async-op wrapper.

Consistency goal: after this, compiled fs/promises, compiled callback-async, and the interpreter all use the same "real async op → event-loop resume" path. Worth doing alongside the callback child rather than after, so the wrapper is written once.

Approach B note: under the primitive:fs facade, the primitive exposes the real Task-returning ops (the interpreter already has FsAsyncHelpers.*Async); the TS facade just awaits them. This child then reduces to "make the fs primitive's async ops genuinely backgrounded."

Acceptance

• A compiled fs/promises op overlaps with concurrent work (e.g. a long read does not block a setImmediate/timer that should interleave) — add a test asserting interleaving / non-blocking behavior.
• Identical results + error codes interpreted vs compiled.
• No regression in dotnet test / Test262 / conformance.

[nickna]

De-risking finding from the #969 async proof

While landing the primitive:fs migration (#969) I ran the "1 async proof": genuinely background the compiled primitive:fs/promises.readFile instead of Task.FromResult, to validate the real-backgrounding path this issue needs.

What works: Emitting Task.Factory.StartNew(thunk, state) (BCL-only, no closure — (path, encoding) ride in the StartNew state and are unpacked by a static FsReadFileThunk that calls FsReadFileSync) and wrapping it via the existing WrapTaskAsPromise → new $Promise(task) is functionally correct: await and .then/callback all resolve the right data, byte-identical to the interpreter, and the output stays standalone (BCL-only).

The gap this issue must close: $Promise's Task-adopting constructor (RuntimeEmitter.TSPromise.cs) only stores _task — it does not Ref the event loop while the task is pending. With Task.FromResult the task is already complete so nothing races; with a genuinely-pending Task.Run-backed task, a fire-and-forget fs.readFile(p, cb) / unawaited promise can race program exit — the event loop drains and the process exits before the background task completes and its continuation runs. Observed as a flaky empty-output test (Fs_CallbackReadFile_MissingFile_PassesError(Compiled) failed ~2/5 runs under real backgrounding; 100% deterministic once reverted to Task.FromResult).

So #971's core work is event-loop ref-counting for adopted Tasks — the compiled counterpart of the interpreter's BuiltInAsyncMethod.refsEventLoopWhileInFlight (which does interpreter.Ref() + task.ContinueWith(Unref)). Concretely: when WrapTaskAsPromise/$Promise(Task) adopts a not-yet-completed Task, it should Ref the $EventLoop and Unref on completion, so the loop stays alive exactly as long as real I/O is in flight (mirroring Node). Once that exists, flipping each FsXxxAsync from Task.FromResult(FsXxxSync(...)) to the Task.Factory.StartNew thunk pattern is mechanical and per-op.

For now (#969) FsReadFileAsync stays deterministic Task.FromResult; the in-code comment in RuntimeEmitter.FsAsync.cs records this boundary.