Fix(tool-call-detector): handle non-numeric strings in numeric operators

[Jean-Regis-M]

Summary

Fixes #131: Prevents unhandled ValueError when actual value is a non‑numeric string in numeric operator conditions.

Problem

In _check_condition, numeric operators (gt, gte, lt, lte) directly convert actual and expected to float. If actual is a non‑numeric string like "pending", float(actual) raises ValueError, crashing the detector coroutine. This allows an attacker to cause denial‑of‑detection by sending a single malformed event.

Root Cause

The code lacks exception handling for float conversion. The earlier None guard does not protect against non‑numeric strings. This leads to uncaught ValueError propagating through _check_parameters to check_event, stopping all subsequent event evaluations.

Solution

Wrap the float conversions in a try/except block that catches TypeError and ValueError. On exception, return False (non‑numeric cannot satisfy a numeric condition). The operators are grouped to compute floats once, minimising changes. This preserves existing behaviour for valid numeric inputs.

# Before
if op == "gt":
    return float(actual) > float(expected)
if op == "gte":
    return float(actual) >= float(expected)
if op == "lt":
    return float(actual) < float(expected)
if op == "lte":
    return float(actual) <= float(expected)

# After
if op in ("gt", "gte", "lt", "lte"):
    try:
        actual_f = float(actual)
        expected_f = float(expected)
    except (TypeError, ValueError):
        return False
    if op == "gt":
        return actual_f > expected_f
    if op == "gte":
        return actual_f >= expected_f
    if op == "lt":
        return actual_f < expected_f
    if op == "lte":
        return actual_f <= expected_f