Detect DataFrames inside class methods and control flow; trace external packages by default

[w-martin]

Summary

Investigated a report that typedframes found "no dataframes" in a real repo (catboost/pymc3 alongside pandas, DataFrames collected via an internal SQL package, dataframes passed through Protocol-typed instance methods). Root causes, all fixed here:

• Class method bodies were never visited. Stmt::ClassDef only recursed into a class's body for BaseSchema/ORM subclasses — any ordinary class's methods (the overwhelming majority of real code, including every Protocol implementation) were completely invisible to the checker, no control flow required. Confirmed with a one-line repro.
• Control-flow bodies were never visited. if/for/while/with/try fell into a bare _ => {} — a load call wrapped in a with connection: or try/except (virtually all real DB code) was invisible.
• Instance-method parameter contracts were broken. The "infer a contract from the function's first parameter" heuristic always tainted self/cls instead of the actual DataFrame parameter.

Fixing class-body recursion turned out to be sufficient for Protocol/structural-typing support too — no Protocol-specific code needed, since function resolution here is already name-based rather than type-based.

Also makes external package tracing default-on: when first-party code calls an unresolved function from an installed package and uses the result like a DataFrame (subscript access, or a pandas/polars-shaped method call), that package is now auto-traced — no config needed for the common "internal SQL wrapper package" case. trace_external_packages remains available as a forced, uncapped override; excluded_external_packages is the new opt-out. Auto-discovered candidates are capped at 20 packages/project, and the discovery step is proven not to sweep in pandas/polars' own (often huge) internals, since their calls are always recognized directly and never reach the "unresolved" fallback.

Also bundled in this PR (version bump + comparison/benchmark refresh, folded in from a separate branch since it belongs alongside the change that motivates it):

• Patch bump to 0.4.1 (pyproject.toml, src/typedframes/__init__.py, rust/Cargo.toml).
• Bumped dev-dependency floors (ruff 0.16.2→0.16.3, ty 0.0.69→0.0.72, mypy 2.3.0→2.3.1, pyarrow 25.0.0→25.0.1) and re-locked every examples/comparisons/* subproject against current PyPI releases: great-expectations 1.19.1→1.20.0, static-frame 5.0.0→5.1.1 — everything else in the comparison set was already at latest. strictly_typed_pandas stays pinned to pandas<=2.2.3 per that package's own upstream constraint.
• Re-ran benchmarks/benchmark_checkers.py --update-readme against the bumped toolchain (including a fresh Great Expectations 1.20.0 clone for the large-corpus benchmark, bumping GE_COMMIT per the script's own "bump deliberately on a new release" convention), and updated the README Feature Matrix's "Version tested" row and tool-description version parentheticals to match.

Test plan

• cargo test (162 unit + 13 integration tests, including new coverage for every fix above)
• uv run inv test — 301 Python tests, 100% branch coverage
• uv run inv lint — ruff/ty/bandit/complexipy/clippy/fmt all clean
• Manually verified against the original failure patterns (load call inside if/with/try, inside a plain class method, through a Protocol-typed call site, and via an unconfigured external package) — each now resolves correctly
• Benchmarked auto-discovery overhead on a synthetic 300-file project with/without a populated .venv: ~11.2ms in all cases, no measurable regression when nothing external is actually used
• uv lock clean in all 10 examples/comparisons/* subprojects, no resolution conflicts
• Benchmark script ran end-to-end (fresh Great Expectations 1.20.0 clone, 485 files) and wrote the updated table into README.md