Windows CI: deploy_component (restart:true) hangs after npm pack — risk-query integration suite cancelled at 319s

## Summary

The `Component: risk-query` integration suite (`integrationTests/components/risk-query.test.ts`) failed on Windows CI with every child test cancelled after the parent ran 319s. The underlying failure is a **server-side hang in `deploy_component` (with `restart: true`)**: the Harper instance log stops cold right after the deploy's `npm pack` subprocess emits its stdout, and nothing further is ever logged — no restart, no error — for 5+ minutes until the job gives up.

Evidence run: [Integration Tests run 32531526496, job "Integration Tests 1/6 (Windows, Node.js v24)"](https://github.com/HarperFast/harper/actions/runs/32531526496) on `main` (sha f8a5aa90).

## Timeline from the failing job

- `22:10:54` — instance dir created, `startHarper` begins
- `22:11:05.909` — `Harper successfully started.`
- `22:11:05.965` — the `deploy_component` operation is received (`[operation]` log entry)
- `22:11:06.849` — `[risk-query:spawn:npm.cmd:stdout]: [` — the start of `npm pack --json` output; **this is the last line the instance ever logs**
- `22:16:14` — the suite fails: `TypeError: fetch failed` with `[cause]: HeadersTimeoutError ... code: 'UND_ERR_HEADERS_TIMEOUT'` — undici's default 300s headers timeout expiring on the `deploy_component` POST, i.e. the operation never sent a response
- all 9 child tests report `test did not finish before its parent and was cancelled`

319s parent runtime = ~11s startup + the 300s headers timeout + teardown, so the whole failure is one `sendOperation(deploy_component)` call that never got response headers.

## Why this doesn't look like plain runner slowness

`npm pack` itself completed in under a second (its stdout arrived). After that the deploy path went silent server-side — over 5 minutes with zero log output at debug level. Windows CI being slow (the known pattern) would show slow progress, not no progress, so this looks like a genuine deadlock/hang in the deploy path on Windows — plausibly in the `npm.cmd` spawn handling (stdout/exit draining) or in the restart sequencing that follows packing.

## Quarantine

The suite is skipped on `win32` (with a pointer to this issue) so a single wedged Windows job stops taking the Integration workflow red. It still runs on Linux/macOS. If the deploy hang is fixed, remove the skip in `integrationTests/components/risk-query.test.ts`.

Note the client side also had no bounded timeout: the readiness poll in the suite's `before()` computes a 30s deadline but only checks it between fetches, so any single hung `fetch` burns undici's full 300s first. The quarantine PR adds `AbortSignal.timeout` to the poll fetch as hygiene, but that only fails faster — the server-side hang is the defect.

## Reproduction

Not reproduced locally (Linux); the hang is Windows-only on the evidence so far, and this was its only completed-and-failed occurrence in the recent window examined. Treat one clean re-run as weak evidence — the suite runs on every push, so recurrence data will accumulate quickly if the hang is structural.