fix(hooks): session-naming abort on role-resolution failure, not silent downgrade

[Brian Krabach (bkrabach)]

Problem

SessionNamingHook._call_provider silently fell back to the session's primary (expensive) model whenever a configured model_role failed to resolve.

The code collapsed two distinct scenarios into one silent fallback:

1. No model_role_resolver capability registered (no routing bundle installed) — falling back to the priority provider is legitimate and intended
2. Resolver IS registered but resolution fails (returns no candidates, or raises) — this is a failure of an explicitly-configured routing preference

In case 2, the code logged logger.warning("model_role %r resolved to no candidates", ...) and then fell through to provider = next(iter(providers.values()), None), quietly running a trivial background classification chore on the user's primary model.

Production observation: A transient anthropic.APIConnectionError inside the resolver's list_models() made the fast role resolve to nothing, and session naming silently ran on claude-sonnet-5 instead of haiku-4.5. Cost leak and latency regression on background work.

Solution

Case 1 (no resolver capability) is unchanged — still logger.debug + fallback.

Case 2 (resolver fails) now aborts the naming attempt (return None) and logs a WARNING that names the consequence:

• "skipping session naming for this turn to avoid silently routing onto the primary (expensive) provider"
• "will retry on a later turn"

The await resolver.resolve(...) call is now wrapped in try/except Exception; a raised exception is treated the same as "resolved to nothing" (previously it propagated uncaught out of _call_provider).

Why aborting is safe: Naming is best-effort and self-retrying: the trigger is if current_turn >= initial_trigger_turn and not has_name:, so while the session still has no name the next turn re-attempts. The caller already treats a falsy return as a normal no-op. Skipping one naming attempt costs nothing; silently buying the primary model costs real money and latency on every attempt.

No retry loops, backoff, or caching were added — this is a fail-loud fix, not a resilience redesign. (Model-list caching was addressed separately in amplifier-bundle-routing-matrix PR #41, which narrows the window; this closes the remaining case where the very first resolution of a session fails.)

Evidence

Behavioral proof with a real SessionNamingHook and a real AnthropicProvider instance, spying on provider.complete() — the load-bearing question is not what got logged but whether the expensive primary model actually gets called:

scenario	primary model called?
resolver returns [] (the production failure)	False — aborted
resolver raises ConnectionError	False — aborted, no propagation
no resolver capability at all (regression guard)	True — legitimate fallback preserved

Tests: modules/hooks-session-naming/tests/ 21 passing at dea5bd8 → 25 with 4 new tests in TestModelRoleResolution:

• test_resolver_empty_result_aborts_without_calling_provider — resolver returns [] → _call_provider returns None and provider.complete is never awaited (load-bearing)
• test_resolver_exception_aborts_without_calling_provider — resolver raises → same, exception does not propagate
• test_resolver_empty_result_logs_warning — caplog assertion for abort path
• test_resolver_exception_logs_warning — caplog assertion for exception path

The two regression guards for the preserved-fallback and happy-path cases already existed in the file and pass unmodified:

• test_model_role_falls_back_when_no_resolver_capability
• test_model_role_uses_resolved_provider_and_model

Note for reviewers on running the tests: This module's tests need the compiled amplifier_core, so they run via the amplifier tool venv's site-packages on PYTHONPATH rather than a bare pytest in the module venv. See the test file header for the invocation.