Support long login sessions within Windows credential limits

[kosesena]

Browser login stores the session JWT and token together, which can exceed the Windows Credential Manager's 2560-byte limit and trigger the CredWrite failure reported in #276.

This keeps short entries compatible and stores larger secrets as bounded ASCII chunks in the OS keyring. It publishes a versioned manifest after all chunks are written, retains the old value on a failed write, removes replaced/deleted chunks, and supports rollback and corrupt-entry reads. No plaintext file fallback or additional dependency is introduced.

Validation: regression test fails on the original implementation under a simulated Windows byte limit; 60 targeted tests pass with 100% statement and branch coverage of keyring_store. Full offline suite: 3732 passed, with the same two terminal-rendering failures reproduced on unmodified main (3723 passed there). Actual Windows validation and the complete repository gate remain pending. The local gate passed lint, formatting, type, architecture and complexity checks, then stopped because markdownlint is unavailable.

Draft for maintainer review of the storage approach; not claiming Windows CI or all required gates are green.

[aikido-pr-checks]

Exposed secret in tests/test_keyring_large.py - low severity
Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

_{Reply @AikidoSec ignore: [REASON] to ignore this issue.
More Info}

[kosesena]

This is a synthetic test fixture, not a credential. The value is constructed locally as "assemblyai-chunks-v1:" + "a" * 32 + ":1"; it is not issued by any service and grants no access. The test intentionally uses a string matching the versioned chunk-manifest format to verify that a secret with that shape can still be stored and read back unchanged. Changing it to a non-matching placeholder would remove that regression coverage.