Harden Windows Python lifecycle ownership with Job Objects

## Problem PR #106 bounds Python bridge process trees on POSIX by retaining process-group ownership after the direct Python parent exits. The Windows path still uses `taskkill /T /F` and the direct parent's `exitCode` as its liveness proxy. If the direct parent exits before one of its descendants, the current Node process record cannot establish that the descendant is still owned or has been terminated. Review finding: https://github.com/rookslog/zlibrary-mcp/pull/106#discussion_r3771229610 ## Release decision Hard Windows process-tree ownership is intentionally deferred from #106 and from v1.5. PR #106 must continue to provide and test: - hard POSIX process-group ownership through timeout, abort, and server shutdown; - cooperative Python cancellation and partial-download cleanup; - the existing best-effort Windows `taskkill /T /F` path; - an explicit statement that Windows hard ownership is not host-corroborated. This issue is deliberately unslotted. Assign it to a version only when a later release map takes ownership of the Windows lifecycle guarantee. ## Required outcome Provide an OS-backed Windows lifecycle owner whose identity survives direct-parent exit. The expected direction is a native launcher or equivalent integration using Windows Job Objects; a Python supervisor is insufficient because it can itself exit before its descendants. ## Acceptance criteria - The Python bridge and every descendant it creates are assigned to one Job Object before user bridge code runs. - Job lifetime is retained independently of the direct Python parent's lifetime. - Timeout, request abort, and MCP server shutdown terminate the owned job and observe that no live descendant remains. - Normal shutdown permits cooperative Python cleanup before forced termination; forced termination has a finite grace boundary. - A real Windows CI job covers a direct-parent-exits-first descendant and an uncooperative descendant. - The npm package includes or reproducibly builds the required Windows component for each supported Windows architecture. - The launcher and tests preserve stdio purity: stdout remains exclusively the MCP JSON-RPC channel. - Documentation distinguishes hard Windows ownership from the best-effort fallback and names the tested Windows environments. ## Out of scope - Changing provider timeout budgets or the provider error vocabulary established by #106. - Replacing POSIX process-group ownership. - Claiming Windows support based only on Linux-host mocks of `taskkill`. ## Flip condition Move this into an earlier release only if Windows becomes a primary supported deployment target or a release explicitly promises equal cross-platform process-lifecycle containment.