build(xterm): make the regenerator runnable on Windows and drop dead paths

Readiness review on the restore found one blocking gap and two cheap
cleanups. None of them change the emitted patch, which is byte-identical
before and after.

The generator could not run on Windows at all. Three sites called npm
through execFileSync with shell:false, but npm ships as npm.cmd there,
execFile applies no PATHEXT, and since CVE-2024-27980 it refuses a .cmd
target without a shell. That matters because this harness arms a
blocking gate whose documented remedy is --write, so a Windows
contributor who tripped the gate had no remedy except hand-editing a 7MB
minified bundle, which is the practice the gate exists to abolish. Four
sibling scripts in config/scripts already handle this; the fix follows
them and lands in run(), so the manifest-driven build step is covered
too. git and tar are real executables in System32 and keep resolving
without a shell, which avoids quoting exposure on paths with spaces.

deleteGeneratedSourcemaps was unreachable, since the policy is include.
Deleting it left "delete" as a legal policy value that nothing honoured,
so a manifest asking for it would have silently shipped sourcemaps that
do not match the bundle. The enum is narrowed and an unrecognised policy
now throws rather than falling through.

generatedHunks moved into the test file rather than being dropped; its
partition assertion, that generated and source hunks reconstruct the
whole patch, is worth keeping.

The -text attribute now covers all five patch files. pnpm hashes each of
them byte-for-byte, so the CRLF hazard the xterm patch was protected
from applies equally to node-pty and the three addons. All five were
already LF in the object DB, so this pins existing behaviour. -diff
stays scoped to the xterm patch, since the others are readable.

The doc's claim that the addons reproduce byte for byte is now dated and
marked a one-off measurement rather than an invariant, because nothing
re-runs it.

Effective lines fall from 591 to 568 against the 600 budget. Still the
largest file in config/scripts, and adding a second package to the
manifest would need a split first.

docs/reference/xterm-patch-regeneration.md

@@ -41,13 +41,12 @@ and are tracked separately; see [Known Gaps](#known-gaps).
    silently patch the wrong tree.
 5. Sourcemaps move with the bundle, and are never silently omitted. The patch
    moves the code, so dropping only the map hunks would ship offsets pointing at
-   the wrong lines. `sourcemaps.policy` in the manifest picks between patching
-   them (`include`, today) and deleting them (`delete`); omitting them is not an
-   option either setting offers. `include` costs about 5.8 MB of the emitted
-   patch and is required because
+   the wrong lines. `sourcemaps.policy` accepts `include` and nothing else: it
+   costs about 5.8 MB of the emitted patch and is required because
    `src/renderer/src/components/terminal-pane/terminal-ime-xterm-transaction-events.test.ts`
    reads `lib/*.map` and asserts the mapped `Version.ts` matches the runtime
-   version. `delete` becomes available again only once nothing reads them.
+   version. Deleting the maps was once an option; the code that did it was
+   removed as unreachable, so re-adding the policy means re-adding that code.
 6. `--check` is the authority on the lockfile, not `pnpm install`. pnpm writes the
    patch hash in two places — `patchedDependencies` and every resolution key that
    depends on the patched package — and on a warm store it will leave the
@@ -231,8 +230,10 @@ and which folding them into this manifest would also fix.
 Both addons do build from the pinned commit: the registry stamps
 `53a98a720ae4a973e384fa2440880d09537132f3` on `addon-webgl@0.20.0-beta.286` and
 `addon-serialize@0.15.0-beta.287` alike, despite the mismatched version numbers.
-Their published `lib/*.mjs` and `lib/*.mjs.map` reproduce byte for byte from that
-commit; this was measured, not assumed.
+On 2026-08-17 their published `lib/*.mjs` and `lib/*.mjs.map` reproduced byte for
+byte from that commit. That was a one-off measurement, not an invariant: no check
+in this repo re-runs it, so treat it as a starting point to re-measure rather than
+as something the harness holds true.
 
 What blocks folding them in is the other half of their published output. Both
 also ship a CJS `lib/addon-*.js`, and the root `package` script does not build