Background

Split out of #481/#483 (small-model context-management work).

`McpChatConfig.context_length` and `LlmClient::with_num_ctx` exist and work correctly where they're wired (e.g. `ahma_tui`'s `resolve_token_prefs` → the daemon-hub `SubmitPrompt` path in `ahma_core::agent`'s hub prompt runner). But several other `LlmClient::new(...)` call sites never call `.with_num_ctx(...)`, and `ahma_core::agent::build_agent_run_context` hardcodes `context_length: None` even though `resolve_llm_connection` already resolves the real `num_ctx` right there.

Why this matters

Two features now depend on `context_length` being populated to do anything useful:

1. Proactive compaction ([ahma_core] Proactively compact conversation history before context fills up #483) — a complete no-op whenever `context_length` is `None` (no denominator to compute a fill fraction against).
2. Generation-length capping (tracked separately, see the num_predict/max_tokens issue) — needs the window size to derive a sensible response budget.

Both are currently inert on any code path that doesn't already thread `context_length` through by hand.

Scope

• Audit every `LlmClient::new(...)` / `LlmClient::for_provider(...)` call site across `ahma_core`, `ahma_tui`, and `ahma_bin`.
• Fix `build_agent_run_context` to pass through the `num_ctx` it already resolves.
• Confirm the daemon-hub `SubmitPrompt` routing path (the TUI's actual production chat path) gets `context_length` end-to-end — this was traced during [ahma_core] Detect length-truncated responses and auto-continue instead of stalling #481/[ahma_core] Proactively compact conversation history before context fills up #483 but not exhaustively audited for every entry point (e.g. cluster/remote routing).
• Add a regression test asserting `context_length` is non-`None` whenever `num_ctx` is configured for a provider, for at least the primary TUI chat path.