fix(context): pass custom_providers in aux compression and fallback paths

Problem

Users who pin context_length on a model in custom_providers see the main agent honor that override but the auxiliary compression model fall back to the default 256K — even when it's literally the same model. This produces a confusing startup warning and silently lowers the compression threshold every session.

What goes wrong (user perspective)

Take a custom_providers entry with a per-model context override (typical for the 1M-context Opus variant against a custom proxy):

model:
  default: claude-opus-4-7[1m]
  provider: my-vertex-proxy

custom_providers:
- name: my-vertex-proxy
  base_url: http://127.0.0.1:8788
  api_mode: anthropic_messages
  models:
    claude-opus-4-7[1m]:
      context_length: 1000000

compression:
  threshold: 0.5     # default — compress at 50% of context

Expected: compression triggers at 500K tokens (50% of 1M).

Actual: at session start, this warning appears:

⚠ Compression model claude-opus-4-7[1m] (127.0.0.1) context is 256,000 tokens,
  but the main model claude-opus-4-7[1m] (custom)'s compression threshold was
  500,000 tokens. Auto-lowered this session's threshold to 256,000 tokens so
  compression can run.

Both labels in that message are the same model — claude-opus-4-7[1m] against the same custom provider. Yet Hermes resolves it to two different context windows: 1M for the main agent (correct), 256K for the compression model (wrong). The session quietly runs at half the configured threshold and the user has to either ignore the warning every session or manually drop compression.threshold to 0.25.

Root cause

agent/model_metadata.py:1229's get_model_context_length() accepts a custom_providers keyword. When supplied, step 0b in its resolution order checks custom_providers[].models[].context_length for an explicit override. Without it, that step is skipped and resolution falls through (eventually) to the DEFAULT_FALLBACK_CONTEXT of 256K for unknown custom endpoints.

There are four call sites in run_agent.py. Two pass custom_providers; two don't:

Site 2655 is what produces the warning. Site 7635 has the same bug but is latent — only triggers when a user has both a custom-provider main model AND a fallback_model; the symptom would be the fallback's compressor mis-sizing its threshold.

Fix

Mirror the existing pattern already used at run_agent.py:2382-2389 — load custom_providers from current config (defensively wrapped in try/except so a load failure doesn't break the path) and pass via the existing custom_providers= keyword:

_aux_custom_providers = None
try:
    from hermes_cli.config import (
        load_config,
        get_compatible_custom_providers,
    )
    _aux_custom_providers = get_compatible_custom_providers(load_config())
except Exception:
    _aux_custom_providers = None

aux_context = get_model_context_length(
    aux_model,
    base_url=aux_base_url,
    api_key=aux_api_key,
    config_context_length=getattr(self, "_aux_compression_context_length_config", None),
    provider=getattr(self, "provider", ""),
    custom_providers=_aux_custom_providers,   # ← new
)

Same shape applied at site 7635 for the fallback path.

No new code paths. No behavior change for users not using custom_providers.

Test plan

• uv run pytest (existing suite passes)
• Repro case: configure custom_providers[].models[].context_length: 1000000 and compression.threshold: 0.5 against a custom Anthropic-compatible endpoint; start a session → warning does not appear, context_compressor.threshold_tokens is 500,000.
• Fallback case: configure as above plus a fallback_model pointing at the same custom provider; force the primary to fail (e.g. wrong port); confirm fallback's context_compressor.context_length reflects the per-model override (not the 256K default).