test(agent): refresh two assertions that predate current retry/fallback behavior

[OmarB97]

What does this PR do?

Fixes the two failing tests in tests/run_agent/test_run_agent.py. Both encode
call shapes that recent changes moved past; in both cases I checked the current
behavior is the intended one rather than assuming.

test_codex_content_filter_incomplete_routes_to_policy_fallback

Expected: _try_activate_fallback()
  Actual: _try_activate_fallback(<FailoverReason.content_policy_blocked: 'content_policy_blocked'>)

#269 threads the classified FailoverReason into the fallback switch. The test
predates that and asserted the bare call. Asserting that the reason is
propagated is strictly stronger, and it is what the test's own name
(routes_to_policy_fallback) claims to cover — the test already asserts the
same enum on the hook event two lines below.

test_output_cap_retry_request_pressure_lower_bound

assert 1 == 903

The output-cap retry no longer stops at
min(provider_available, context_length - estimate) - 64. It is then anchored
to output_tokens_that_fit():

_local_fit = output_tokens_that_fit(old_ctx, api_messages)
if _local_fit is not None:
    safe_out = max(1, min(safe_out, _local_fit))

That helper is documented as "the single source of truth for 'how many output
tokens fit'", and it reserves the input conservatively (an over-reservation
factor plus pad and window margin) so the value it returns is one the provider
will actually accept. It exists because some servers — notably vLLM — report the
offending input as a max_tokens-dependent lower bound, which makes a naive
shrink-and-retry loop never converge.

This test's scenario is a ~199k-token system prompt in a 200k window, i.e. a
near-full window, so the conservative reservation legitimately binds below the
plain arithmetic and the cap floors at 1. The test re-derived the old formula
and so went stale. The expectation now applies the same clamp the code does.
The floor-at-1 behavior itself already has dedicated coverage in the sibling
test_output_cap_retry_safety_floor_at_one.

Related Issue

No filed issue — surfaced once #286 unblocked uv sync --locked and the Python
test slices ran for the first time since 2026-07-10.

Type of Change

• ✅ Tests (adding or improving test coverage)

Changes Made

• tests/run_agent/test_run_agent.py — assert _try_activate_fallback receives FailoverReason.content_policy_blocked; include the output_tokens_that_fit() clamp in the expected retry cap.

How to Test

pytest tests/run_agent/test_run_agent.py -p no:randomly -q

Before: 2 failed, 434 passed. After: 436 passed.

⚠️ Run with an isolated HERMES_HOME. The suite reads the developer's real
~/.hermes/config.yaml, which can diverge from CI.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run the full affected file: 436 passed
• I've added tests for my changes — N/A, this PR repairs existing tests
• I've tested on my platform: macOS 15 (Darwin 25.6.0), Python 3.11.15

Documentation & Housekeeping

• I've updated relevant documentation — N/A
• I've updated cli-config.yaml.example — N/A
• I've updated CONTRIBUTING.md or AGENTS.md — N/A
• I've considered cross-platform impact — N/A, test-only
• I've updated tool descriptions/schemas — N/A