fix: bound conversation compaction budgets

[KevinXia69]

Summary

• cap the conversation-history planning budget at 131,072 tokens
• cap summary output at 16,384 tokens and respect a lower active generation limit
• cap raw anti-drift rebuild eligibility at 131,072 tokens
• keep the recent-history split ratio independent from the summary output cap so compaction retains sufficient hysteresis
• ensure the requested summary target never exceeds a small generation limit

Why

The existing ratio-only calculations scale every compaction dimension with the model context window. For a configured 983,616-token window, they produce roughly:

• 344,265 tokens of planned conversation history
• 137,706 tokens of requested summary output
• 491,808 tokens eligible for raw-summary rebuild

The summary request can exceed provider output limits and make compaction disproportionately expensive. This change keeps the existing rolling-summary architecture while bounding those costs. With the current default 4,096-token generation limit, the same model now uses a 131,072-token history plan, a 4,096-token summary cap, and a 78,643-token recent verbatim tail. That leaves meaningful headroom before the next compaction instead of triggering it again after only a small amount of new history.

The history budget remains a soft planning target: the newest non-empty message is still preserved if that single message exceeds the target.

Testing

• pytest tests/services/session/test_context_builder.py tests/services/config/test_context_window_detection.py tests/services/model_selection/test_llm_selection.py tests/services/session/test_turn_runtime.py (88 passed)
• pre-commit run --files deeptutor/services/session/context_builder.py tests/services/session/test_context_builder.py