test(windows): validate crash recovery boundaries

[liugddx]

Summary

• terminate runtime crash children through the shared process-tree terminator and wait for the Windows handle-close boundary
• close every runtime continuation/resume SQLite lease so crash harness workers terminate deterministically on Windows
• enable the SqliteRuntimeStore and long-term-memory real-process crash suites on Windows
• regenerate the Windows skip inventory from 65 to 55 declarations after the merged named-pipe coverage and these crash suites

Windows evidence

• runtime continuation: all 5 committed-prefix SIGKILL boundaries pass
• runtime resume: all P0-P11 committed ledger prefixes pass
• SqliteRuntimeStore: 10 transaction, recovery-bundle, side-effect, and workspace-baseline crash boundaries pass
• long-term memory: post-COMMIT item and operation receipt recovery passes

Validation

• npm --workspace @maka/runtime run build
• node --test --test-reporter=spec packages/runtime/dist/__tests__/runtime-continuation-crash.test.js
• node --test --test-reporter=spec packages/runtime/dist/__tests__/runtime-resume-crash.test.js
• npm --workspace @maka/storage run build
• both enabled Storage crash suites: 11 pass / 0 fail / 0 skip
• Runtime and Storage typechecks
• focused Biome checks
• npm run windows:inventory
• node --test scripts/windows-test-inventory.test.mjs
• git diff --check

Addresses the Windows crash/recovery harness item in #2142.

[Astro-Han]

Thanks — this is a useful improvement to the Windows crash-recovery coverage. Reusing the existing process-tree terminator, waiting for the Runtime child close boundary, and explicitly closing SQLite stores are all appropriately scoped changes. The crash cases themselves protect real COMMIT/rollback boundaries and are worth keeping.

A few non-blocking P3 follow-ups:

• The newly enabled Storage crash suites still kill the child and wait only for exit. Waiting for close as well would make Windows handle cleanup less prone to intermittent races.
• The Windows workflow currently runs the Storage crash suites but not the two modified Runtime crash files. A focused Runtime step would give the new Windows taskkill path continuous coverage without running the full workspace.
• Where practical, closing reopened stores in finally would prevent cleanup failures from obscuring the original assertion.

These do not need to block this PR. The current implementation and CI evidence look sufficient to merge. Thanks!