feat(runtime): add Session context-window caps

[lihuiyang1024]

Description

Closes #153.

The reasoning controls from #161/#162 already cover the first half of the issue. This adds the remaining manual context-window control as a Session selection for future Turns, shared by Desktop and the interactive CLI.

Behavior

• null / auto follows the selected model's published context window
• an explicit cap may only narrow that window and must leave room for the configured generation limit
• each accepted or queued Turn freezes the effective value in its immutable ExecutionProfile
• changing the Session later never reinterprets an active or already accepted Turn
• Paper2Code planning and implementation phases inherit the same Session cap

Changes Made

• add the optional context cap to ExecutionSelection, canonical Session metadata, Thread projection, SQLite migration v17, and App Server protocol
• preserve older App Server clients that omit contextWindow; explicit null clears the override
• add context presets to the Desktop model picker and show the active cap on its trigger
• add /context 64k and /context auto to the TUI, including human k/m parsing
• document the control in the English and Chinese README and model guide
• add regression coverage for validation, frozen Turn profiles, workflows, persistence/migration, protocol compatibility, Desktop requests, and TUI persistence

Verification

• ruff check on all changed Python files
• ruff format --check on all changed Python files
• focused Python verification — 20 passed
• persistence + reversible migration verification — 14 passed
• Desktop npm test — 31 files, 195 tests passed
• Desktop npm run build
• Desktop npm run check:protocol, npm run typecheck, and npm run lint

Checklist

• Changes tested locally
• Code reviewed
• Documentation updated
• Unit tests added

[Zongwei9888]

Merged today as b9a945e ("Merge repaired PR #203") with your commit intact. This was the most complete external contribution we have had: the cap really reaches the compaction gate and request trimming (we measured the trigger moving from ~222k to ~49k for a 64k cap on a 256k model), the per-Turn freeze holds for queued Turns and forks, the v17 migration round-trips, and the protocol change was regenerated rather than hand-edited.

Three small repairs went on top (4c68774): thread/start now validates an explicit cap the same way thread/execution/update does instead of letting the first Turn reject it; ThreadStartParams.contextWindow accepts null in the schema as the dispatcher already did; and the TUI guide's command table gained the /context row. Two optional follow-ups if you feel like it: a --context flag for exec/loop, and a friendlier path when a stale cap exceeds a newly selected model's window (today that surfaces as a ConfigError on the next Turn). Thank you for the thoroughness — and for taking #101 and #152 too; replies are on both.