eval:list accepts malformed --limit values and can hide all runs #1683

Observed problem

bun run eval:list -- --limit <value> parses the limit with parseInt and never validates the full token. That means malformed values are accepted or produce confusing successful output.

Current behavior on upstream main

On current origin/main (920a13a1), with two eval JSON files in the eval directory:

HOME=/tmp/repro bun run scripts/eval-list.ts --limit 1abc

prints one row and exits successfully because parseInt("1abc", 10) becomes 1.

HOME=/tmp/repro bun run scripts/eval-list.ts --limit nope

also exits successfully, but runs.slice(0, NaN) shows zero rows even though the footer reports two total runs.

Expected behavior

--limit should require a positive integer token. Invalid, zero, negative, decimal, or suffixed values should fail with a clear error instead of silently changing the displayed history.

Duplicate searches performed

I searched open issues and PRs for:

• eval list limit
• eval-list
• eval:list --limit
• scripts/eval-list.ts

I did not find an open issue or canonical PR for this behavior. The nearest historical hits are broad eval infrastructure PRs, not a fix for eval:list --limit validation.

Candidate fix shape

Add strict positive-integer parsing for scripts/eval-list.ts --limit, print a concise stderr error for invalid values, exit non-zero, and add focused regression coverage for malformed and valid limits.