hermes - 💡(How to fix) Fix Context overflow without provider max should not probe-step context length [2 pull requests]

Bug Description

When a provider returns a context-overflow error but does not include the actual maximum context length, Hermes currently falls back to the next built-in probe tier. For a session configured with a 1M context window, that means the running agent can silently change its effective context length from 1,000,000 to 256,000, then continue descending to 128,000, 64,000, etc. on repeated overflow retries.

This makes a configured long-context session appear to lose its 1M window even though the config file is unchanged.

Related to #32423, but this issue tracks the specific root cause in context-overflow recovery: guessed probe-tier step-down when the provider did not report a concrete max context limit.

Steps to Reproduce

1. Configure a provider/model with a large context length, for example:

model:
  provider: custom
  default: gpt-5.5
  context_length: 1000000

1. Run a long session until the provider rejects a request with a generic context overflow error such as:

Your input exceeds the context window of this model. Please adjust your input and try again.

1. Ensure the provider error text does not include a concrete maximum like 272000 maximum or maximum context length is 272000.
2. Observe Hermes' recovery path.

Expected Behavior

If the provider does not report a concrete max context length, Hermes should:

• keep the configured/runtime context_length unchanged;
• attempt conversation compression;
• retry only if compression actually reduced the message set;
• avoid treating built-in probe tiers as provider-confirmed context limits.

If the provider does report a smaller concrete limit, Hermes may use that provider-reported limit.

Actual Behavior

Hermes calls the probe-tier fallback and logs a step-down similar to:

Context length exceeded — stepping down: 1,000,000 → 256,000 tokens
Context too large (...) — compressing (...)

If compression aborts or does not reduce the payload enough, subsequent overflow attempts can continue stepping down through lower probe tiers.

Proposed Fix

• Add a helper that only returns provider-reported lower context limits.
• In the conversation loop, stop using get_next_probe_tier() as a fallback when parse_context_limit_from_error() cannot extract a concrete max.
• Keep context length unchanged and rely on compression when the provider gives no max.
• Continue allowing provider-confirmed lower limits to update the compressor context length.

Test Coverage

Add regression tests for:

• generic overflow without a provider limit returns no context-length update;
• explicit provider limit still updates to that limit;
• provider limit greater than or equal to the current runtime context is ignored.