Give scoring something to anchor on: focal athlete, per-sport target class, thread cap

[ralyodio]

Three findings from your basketball run — 1,287 tracks, 34,089 detections, zero suggested moments.

1. Without an athlete to follow, a moment is arithmetically impossible

Three of the seven scoring signals need a focal track, and together they carry 0.6 of the 1.15 total weight. With no focal track the only signal that can fire is high_motion at 0.1.

scenario	best possible score	threshold
no athlete marked	0.087	0.35
with a focal athlete	0.609	0.35

Not "unlikely" — impossible. The app said "Nothing suggested yet — run analysis", ran analysis for a minute, and completed with nothing, never mentioning it could not have succeeded. It now says so before the work starts.

2. Scoring looked for goal whatever the sport

Basketball tracks a hoop, hockey a net, football an end_zone. For those sports both target signals were permanently dark even with a model that saw the thing perfectly. Soccer worked by luck of naming.

Sports now declare their target class, derived from the noun where the two agree and stated explicitly where they don't:

baseball    base        football    end_zone
basketball  hoop        hockey      net
soccer      goal        volleyball  net

A sport with no trackable target resolves to null rather than a name nothing will ever match.

3. The thread cap was tuned on the wrong machine

worker: threads: using 4 (cgroup-aware 24, visible cores 48)

Those two numbers disagreeing is exactly what #10 existed to reveal, and pinning the pool was right — onnxruntime would have sized from 48 on a 24-core allowance. But 4 is now the limit rather than the protection. The cap moves to 8, which is where a model this small stops benefiting rather than the size of the laptop it was measured on.

REELEEL_CV_THREADS overrides it without a deploy, so the real ceiling can be found on the box that has 24 cores instead of guessed on one with 4.

Verification

393 tests pass (7 new), eslint and typecheck clean. The ceiling arithmetic above was computed by running the real plugin weights through the real scoring code, not derived by hand — after a first attempt that got it wrong by counting user_marker, which has a weight but no implementation and so never reaches the denominator.

What to expect

Mark an athlete, re-run on fast. Detection already works; this gives scoring the anchor it needs. If it still finds nothing, the log will now say whether tracks existed and the threshold is simply too high for this footage — which is a tuning conversation, not a bug hunt.