fix(background-terminals): avoid false success after Windows taskkill timeout

[627150795]

Problem

Fixes #408. On Windows, a slow taskkill /T /F helper can exceed its bounded wait, get force-closed, and then fall back to child.kill(). That only terminates the shell and can orphan descendants while the manager reports successful termination.

Value

A timed-out tree kill is reported as unresolved instead of claiming that the full process tree was terminated. This keeps background-terminal state truthful and avoids silently leaving servers or descendants holding resources.

Approach

Treat every Windows taskkill timeout as unresolved, including the case where the helper closes after SIGKILL. Keep the existing time bounds, direct fallback behavior for non-timeout cases, and POSIX behavior unchanged. Cover both graceful and force timeouts, with the shell still alive or exiting during timeout. Every case stays unresolved and avoids a direct shell signal.

Validation

• bun run check — passed.
• Node 22 bun run test at a2c23a1 — 1427 passed, 1 skipped; Vitest 30 passed.
• The first local full-suite run hit a 150ms subagent watchdog assertion in tests/extensions/subagents/manager.test.ts; its isolated rerun and a second complete suite passed.
• Final-head Node 22, Node 24, and Windows CI must pass before merge.

Impact

• User-visible behavior: uncertain Windows process-tree termination is surfaced as failure/unresolved rather than success.
• Model-visible context/tools: none.
• Runtime/lifecycle: Windows background-terminal cleanup fails closed on taskkill timeout; POSIX behavior is unchanged.
• Persisted config/data: none.
• Compatibility/risk: a timed-out Windows kill remains unconfirmed and may leave processes running. This change prevents the shell-only timeout fallback; it does not implement a reliable retry or Windows Job Object containment.