fix(cli): detect the active Windows code page

[VeraPyuyi]

Related issue

Closes #115

Problem / pressure

Windows child processes can emit bytes in the active console code page. The CLI currently guesses from locale variables, so a zh-SG host with C.UTF-8 variables can fall back to CP437 and corrupt terminal or command output.

Summary

• Probe the active Windows console code page through a corroborated local System32 cmd.exe path, with bounded execution, a retained last-known-good result, and retry after transient failures.
• Parse raw localized chcp output defensively, map Windows-specific aliases such as 54936 to GB18030, and fall back through standard locale precedence and Intl.
• Add end-to-end decoding coverage for CP936 and GB18030, poisoned path inputs, UTF-8, malformed output, locale variants, retry/cache behavior including failed refreshes, and non-Windows behavior.

Before / after

Before	After
Invalid UTF-8 output used a locale guess that could select the wrong OEM code page.	The active code page is detected directly when trusted path inputs agree, with bounded failure-safe locale fallback.

Test plan

• corepack pnpm --dir apps/cli exec vitest run src/utils/encoding.test.ts tests/terminal-manager.test.ts (55 passed)
• corepack pnpm --dir apps/cli typecheck
• corepack pnpm exec oxlint --type-aware apps/cli/src/utils/encoding.ts apps/cli/src/utils/encoding.test.ts (0 warnings/errors)
• corepack pnpm exec prettier --check apps/cli/src/utils/encoding.ts apps/cli/src/utils/encoding.test.ts
• Live Windows CP936 probe and CP936 Chinese round-trip
• git diff --check origin/main...HEAD
• The full CLI suite is not green on this Windows host; independent review observed 2,326 passed, 50 failed, and 11 skipped, with failures in unchanged Windows path, permission, symlink, file-mode, and state-isolation tests.

Context handoff

Instructions for reviewing agents

• Review focus: Inspect command-processor path corroboration, localized chcp parsing, code-page aliases, retry/cache semantics, and decoding integration in the two encoding files.
• Decisions to challenge: Check whether requiring canonical local SystemRoot/WINDIR input that agrees with ComSpec, a synchronous two-second probe, a five-minute success cache, and a 30-second retry delay are appropriate Windows boundaries.
• Plausible failures / evidence gaps: Non-English Windows UIs beyond mocked localized prefixes were not directly available; the full CLI suite has unrelated Windows baseline failures.

Authoring context

• User goal / directives: Contribute a focused Windows decoding fix with test-first implementation and independent review before publishing follow-up commits.
• Constraints / non-goals: Do not change global console state, public APIs, or unrelated Windows test failures; follow the current maintainer-approval policy.
• Risk-bearing decisions: Reject relative, drive-relative, traversal, UNC, or disagreed system paths; cap probe output and time; cache successful detection for five minutes; retain it if a refresh fails; retry after 30 seconds; otherwise use locale fallback.
• Destructive or irreversible behavior: The probe is read-only, never changes the active code page, and does not modify user data.
• Deliberately not done or tested: No direct run across every localized Windows UI; unrelated failing full-suite tests were not modified.
• Unknowns / confidence: Focused behavior is covered, but maintainer agreement on issue [Bug] Windows child-process output can use the wrong code page #115 is still pending and the reviewed follow-up commit remains local until that gate is satisfied.

[VeraPyuyi]

This PR predates the contribution-intake policy introduced in #91. I opened #115 with the reproduction and proposed scope, and I am waiting for explicit maintainer agreement before updating the branch or converting the body to the current template.

While revalidating the existing patch, I found and prepared a fix for an executable-trust issue: the follow-up no longer derives cmd.exe from SystemRoot / WINDIR / ComSpec. It resolves the kernel-owned \\?\GLOBALROOT\SystemRoot\System32\chcp.com alias, executes that read-only utility directly with bounded time/output, and falls back if resolution fails. The matching-malicious-environment regression is covered.

Prepared validation: 48 focused tests passed, CLI typecheck passed, Oxlint and Prettier passed, git diff --check passed, and a live Windows probe returned CP936. I will push the reviewed follow-up and update the PR body after a maintainer confirms #115.