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

## Observed problem

`bun run eval:list -- --limit ` 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:

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

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

```bash
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.