Bug: filterRecommendedRanges hides valid compression ranges at large context windows

[ranxianglei]

Problem

lib/messages/inject/utils.ts contains filterRecommendedRanges which filters the compression recommendation list shown to the model. The filter uses growthThreshold = modelContextLimit * growthRatio as a per-range threshold.

At large context windows (e.g. 1M tokens), growthThreshold = 1,000,000 * 0.05 = 50,000 tokens. Individual compression ranges rarely exceed 50K tokens (a typical tool output is 2-5K tokens). This means:

1. Growth reaches 50K → nudge triggers (correct)
2. But filterRecommendedRanges filters ALL ranges (each < 50K individually) → nothingToCompress = true
3. Nudge gets suppressed → model never compresses → context grows until overflow

Root Cause

filterRecommendedRanges conflates two concerns:

• Nudge trigger threshold: "has enough new content accumulated to warrant compression?" (correct use of growth threshold)
• Per-range display threshold: "is this individual range worth listing?" (should use a much smaller threshold)

Using the same 50K threshold for both means no range ever qualifies for display at 1M context.

Impact

• Large-context sessions (200K-1M) never get specific range recommendations
• Model either gets empty recommendation list (confusing) or nudge gets suppressed entirely
• The growth-based nudge system is designed to work at any scale, but this filter breaks it above ~200K

Reproduction

1. Set context limit to 1M
2. Run a task that generates 50K+ tokens of conversation
3. Observe: nudge triggers but recommendation list is empty (nothingToCompress = true)
4. All individual ranges are filtered because none reaches 50K tokens individually

Suggested Fix

Remove filterRecommendedRanges from the pipeline. Show ALL compressible ranges in the nudge text (with token sizes). Let the model decide what to compress. Death-spiral prevention (compressing tiny ranges) is already handled by minCompressRange in range.ts which checks the aggregate across all ranges in a batch.

The filter's original intent (prevent 19-token garbage compressions) is already covered by minCompressRange. The additional per-range filtering is redundant and harmful at scale.