A deterministic outlier/anomaly tool (z-score or IQR over a column)

"What looks unusual in my spending this month" / "which workout was an outlier" is a real, common personal-analytics question class with no clean path today: the model either eyeballs sample rows (unreliable, not deterministic) or writes ad-hoc `run_python` for something that's actually a standard, well-defined statistical operation.

A narrow tool (`find_outliers` or similar): given a table + numeric column (+ optional group-by), return rows outside N standard deviations or outside 1.5×IQR — computed the same "code computes, not the model" way every other tool works, going through the same evidence/verification path `run_sql` results already do.

**Fit check, not a settled yes:** this is a new built-in tool. `CONTRIBUTING.md` explicitly calls "a narrowly useful built-in tool" a *good* contribution, but `docs/NON-GOALS.md`'s fixed-tool-set rule still applies — a built-in tool is a code change, not a plugin, and needs real demand shown, not just "would be nice."

**Worth deciding together with #117** (a correlation tool): both are "give `run_python`'s most common statistical use case a first-class, always-consistent tool" questions. If either gets built, it's worth deciding both at once rather than piecemeal.

Read CONTRIBUTING.md and docs/NON-GOALS.md first, then compare the existing run_sql and run_python entry points and their evidence/verification paths. Resolve the fixed-tool-set fit and demand question together with #117 before implementation. Done means the scope is accepted or rejected with a clear decision and, if accepted, defined against the existing verification path.

Written by the indexing model from the issue text.