fix(eval-list): reject malformed --limit values with exit 1

[NikhileshNanduri]

Summary

• --limit 1abc silently showed 1 row (parseInt partial-parse)
• --limit nope silently showed 0 rows (NaN slice) while footer still reported full count
• Both now exit 1 with a clear error message

Root cause

parseInt("1abc", 10) returns 1 — JavaScript accepts trailing non-numeric characters. parseInt("nope", 10) returns NaN, and arr.slice(0, NaN) returns an empty array. Neither case produced any error output.

Fix

Replaced parseInt(raw, 10) with:

const parsed = Number.parseInt(raw, 10);
if (!Number.isSafeInteger(parsed) || parsed < 1 || String(parsed) !== raw) {
  console.error(`Error: --limit must be a positive integer, got: ${raw}`);
  process.exit(1);
}

The string round-trip check (String(parsed) !== raw) catches 1abc, 1.5, and other mixed inputs.

Closes #1683.

Test plan

• bun test test/eval-list-limit.test.ts — 6 tests pass
• bun test — full free suite passes

🤖 Generated with Claude Code

[jbetala7]

Collision flag: this overlaps with #1684, which is already open against the same issue (#1683) with the same fix.

Both PRs target scripts/eval-list.ts, fix the same two cases (--limit 1abc → silently shows 1 via parseInt partial-parse, --limit nope → NaN slice shows 0 rows while the footer reports the full count), and reject malformed values with a non-zero exit. #1684 was opened 2026-05-24; this one 2026-05-27, so they were written independently.

One difference worth noting: this PR also bumps VERSION, CHANGELOG.md, and package.json. Those are release-wave artifacts that tend to conflict on rebase and are usually left to the maintainer's release cut rather than carried in a fix PR — might be worth dropping them to keep the diff to the bug fix + test. Flagging the overlap so the identical fix isn't reviewed twice; the validation approach itself looks correct.