fix(cli): validate ranking flags to avoid silently wrong output

[SuperMarioYL]

What

The ranking/filter flags --top, --min-speed, and --min-params were never validated, so invalid values silently produced misleading output instead of a clear error — unlike --vram, --bandwidth, and --gpu-index, which already fail fast.

The motivating case is --top, which flows straight into results[:top_n] in rank_models:

• --top 0 → results[:0] → no recommendations are shown at all, with no explanation.
• --top -5 → results[:-5] → slices from the end, silently returning a truncated subset (the lowest-ranked entries dropped) instead of the count the user asked for.

Negative --min-speed / --min-params thresholds are meaningless (they turn the filter into a no-op), so they are rejected too.

Changes

• Add _validate_ranking_flags() in cli.py (--top ≥ 1, --min-speed ≥ 0, --min-params ≥ 0), following the existing _validate_gpu_flags style, and wire it into both the default recommend flow and the upgrade command (which also exposes --top).
• Defense in depth: clamp top_n in rank_models to results[: max(top_n, 0)] so direct callers of this public helper never get a truncated ranking from a stray negative count.
• Tests for each rejected flag and the clamp behavior.

Notes

• --context-length already raises on non-positive values via parse_context_length, so it is intentionally left unchanged.
• ruff check and ruff format --check are clean; the full test suite passes locally (the only failure is the pre-existing test_run_exits_gracefully smoke test, which needs a working uv/network and fails identically on an unmodified checkout — unrelated to this change).