Review: Critical bug in _clear_low_information_state scoped clearing

BLOCKER: _clear_low_information_state(tool_name) is called but scoped clearing is not implemented

File: agent/tool_guardrails.py
Lines: _clear_low_information_state method and its call in before_call

The new _clear_low_information_state method accepts a tool_name parameter but only implements the None case (clears all low-info state). When called from before_call with tool_name="terminal":

if tool_name == "terminal" and _terminal_probe_family(args) != "filter_probe":
    self._clear_low_information_state(tool_name)
    return ToolGuardrailDecision(...)

The method falls through and does nothing because the else branch for scoped clearing is missing. This means:

1. Running a broad diagnostic like pwd && ls -la does NOT reset the filter-probe low-info state or clear the tool redirect
2. Subsequent filter probes will still hit the redirect instead of being allowed through
3. Test test_terminal_filter_redirect_allows_broad_diagnostic_to_reset will fail on its second assertion because self._tool_redirects["terminal"] is never popped

The fix needs to add scoped clearing that:

• Removes all _low_information_counts entries with k[0] == tool_name
• Pops the tool from _tool_redirects (e.g., self._tool_redirects.pop(tool_name, None))

Minor: _as_positive_int changes behavior for max_chars=0

The old code in conversation_loop.py accepted HERMES_STALL_RETRY_MAX_CHARS=0 as a valid int. The new _as_positive_int helper silently upgrades 0 to the default (400). While 0 is unlikely in practice, this is an undocumented behavioral change.

Minor: _stall_retry_config calls load_config() on every access

Each of get_stall_retry_model, get_stall_retry_max_chars, and get_stall_retry_max_per_turn calls _stall_retry_config(agent) independently. In the fallback path (when agent._stall_retry_config is not set), this could parse the config file 3+ times per stall check. Consider caching the loaded config at module level or using a single call.