fix(server): preserve binary cursor keys on Windows

[knqiufan]

Which issue or RFC does this PR close?

Closes #1463.

Found while investigating the Windows native-service check on #1459. This fix is based directly on master and is independent of the DSH changes.

Rationale for this change

On Windows, os.open defaults to text mode. Writing a random 32-byte cursor key containing LF expands it to CRLF on disk. The first Server process uses the original key and starts successfully; the next process reads the expanded file and fails startup because its length is no longer 32 bytes. Retrying CI can avoid the random LF byte and conceal the defect.

What changes are included in this PR?

• Open new cursor-key files with O_BINARY where supported, preserving exclusive creation and existing POSIX file permissions.
• Make both SQLite and other-database local key persistence tests deterministic with control bytes, and verify the exact persisted bytes. Keep POSIX mode assertions on POSIX systems.
• Exercise actual HTTP pagination across Server lifespans using a key containing LF, proving that previously issued cursors remain usable.
• Run these regressions against the installed wheel in Windows CI, alongside the existing real Task Scheduler lifecycle tests. Print captured Server logs in the failure output before querying a task that test cleanup may already have removed.

Are there any user-facing changes?

Newly generated cursor keys retain their original bytes on Windows, allowing subsequent Server starts. Existing valid keys and cursor formats are unchanged. This does not automatically replace malformed key files or rotate signing keys.

How was this change tested?

• Before the fix, the deterministic persistence/restart checks produced 3 failed, 1 passed on Windows with the same length-validation error found in the CI artifact.
• python -m pytest -q tests/test_cursor_secret.py tests/test_server.py: 51 passed on Windows/Python 3.12.13.
• Built a wheel and installed powercontext[cli,server] plus pytest into a fresh .native-venv; the exact new Windows CI regression command passed 4 tests, including HTTP cursor reuse after restart.
• uv lock --check, uv run --no-sync prek run -a, uv run --no-sync ty check, and git diff --check: passed.
• A local attempt at the real native suite was denied at schtasks /Create by this host. The existing GitHub-hosted Windows lifecycle job remains required to validate install/stop/start/uninstall; its checks are not skipped or relaxed.
• Upstream CI at 2fb02a2e: 17/17 checks passed, including Python 3.11–3.14, SQLite/OceanBase acceptance, and native Linux/macOS/Windows services. The Windows job passed all four deterministic cursor checks and all four applicable real lifecycle tests; its one skip is the macOS-only scenario.

AI usage statement

Implemented with OpenAI Codex. The failure was traced to the uploaded CI service logs, reproduced deterministically on Windows before changing production code, and checked against both source and the built distribution. No credentials or private model configuration are included.