docs: retract the win32 launch note's unproven failure mechanism

[whitelonng]

🤖 Automated. Opened by a DSH agent (deepseek-v4-pro) acting for @whitelonng. Every claim below was verified against this checkout; the Windows-only facts are marked as unverified.

Why

#37's Agent Note (now on master as f637d84a27) asserts a failure mechanism this repository contradicts. I wrote part of that text during the review, so this corrects it in place per .agents/notes/implemented/AGENTS.md ("Rewrite stale facts in place").

The note claimed that node --import tsx/esm <absolute .ts path> fails on Windows with ERR_UNSUPPORTED_ESM_URL_SCHEME, and named packages/sandbox/sandbox-local/src/index.ts:563 as a second, unfixed instance of the same bug.

The counter-evidence

packages/sandbox/sandbox-windows-acl/tests/runner.spec.ts spawns that exact argv:

const runnerEntry = fileURLToPath(new URL('../src/runner.ts', import.meta.url))   // absolute path
spawnSync(process.execPath, ['--import', 'tsx/esm', runnerEntry, ...args])        // same vector
describe.skipIf(!isWin32 || !pwshAvailable())                                     // win32 only

It runs only on Windows, sandbox-windows-acl is absent from vitest.config.ts's Windows exclusion list, and vitest.config.ts:62-68 relies on that suite as the Windows signal that lets src/runner.ts leave the per-file coverage gate — the repository treats that launch as working.

packages/test-support/loader-smoke/src/index.ts:116 launches an absolute path behind a resolved tsx loader in src mode (the default), from .spec.ts files Windows does not exclude.

So neither discriminator the note offered survives:

site	loader argument	entry	Windows
dialog worker, pre-fix	import.meta.resolve('tsx/esm') → file:// URL	absolute	reported failure
sandbox-windows-acl/tests/runner.spec.ts:29	'tsx/esm' bare	absolute	win32-only, load-bearing
loader-smoke/src/index.ts:116	import.meta.resolve('tsx') → file:// URL	absolute	Windows-included spec
sandbox-local/src/index.ts:563	'tsx/esm' bare	absolute	same form as the load-bearing one

Neither "ESM-only versus full tsx entry" nor "bare specifier versus file:// URL" separates the failing site from the others.

What this changes

• ## Problem splits into what is established — the symptom, that koffi was never reached, that replacing the launch fixed the dialog on Windows — and the mechanism, now marked untested. The one factor unique to that call site is named: ELECTRON_RUN_AS_NODE=1 over a process.execPath a packaged host points at its own binary.
• ## Related launch paths turns sandbox-local from a queued fix into counter-evidence. Adopting this launch there remains a reasonable simplification, one that would rewrite the --import tsx/esm assertion in packages/sandbox/sandbox-local/tests/local.spec.ts, but not a bug fix.
• The first ## Consequences bullet no longer asserts the mechanism, only that the launch no longer depends on how a loader chain resolves the worker path.

The shipped fix is untouched and still justified: plain node over a package-local erasable graph needs no loader chain regardless of which mechanism broke it.

Settling it

pnpm vitest run packages/sandbox/sandbox-windows-acl on a Windows host decides between the two readings. Green means the vector is fine and ELECTRON_RUN_AS_NODE is the prime suspect; red means sandbox-local really does carry the same defect and wants its own fix.

Verification

Documentation only — no source or test changes. Three files: the two note languages and their pairing record.

• pnpm run doc-sync — 28 passed, 0 failed
• pre-commit — staged pairing record consistent, whitespace clean