Node CLI silently accepts malformed --pages values such as 1foo

### Describe the bug

The Node CLI parses each `--pages` token with `parseInt`, so tokens that only start with an integer are silently accepted. For example, `1foo`, `1.5`, and `1e2` are all treated as page `1` instead of being rejected.

This can hide typos in scripts while producing incomplete output.

### Steps to reproduce

Using `@firecrawl/pdf-inspector` 1.14.1 and any multi-page text PDF:

```sh
pdf-inspector sample.pdf --pages 1foo --json > malformed.json
pdf-inspector sample.pdf --pages 1 --json > page-one.json
pdf-inspector sample.pdf --json > all-pages.json
```

`malformed.json` contains the same selected-page markdown as `page-one.json`, rather than an argument error. In my check against the three-page `tests/fixtures/thermo-freon12.pdf`, both malformed and page-one commands returned 176 Markdown characters, while the all-pages command returned 5693.

### Expected behavior

Every comma-separated token should be validated as a complete positive integer. `1foo`, `1.5`, empty tokens, and similar malformed values should exit non-zero with an invalid page number error.

### Actual behavior

The parser in `napi/bin/pdf-inspector.mjs` uses:

```js
const n = parseInt(p.trim(), 10);
```

Because `parseInt` accepts a valid numeric prefix, the malformed suffix is ignored.

### Environment

- `@firecrawl/pdf-inspector` 1.14.1
- Node.js 23.10.0
- macOS arm64

Start in napi/bin/pdf-inspector.mjs at the --pages parsing code that calls parseInt. Reproduce the issue with tests/fixtures/thermo-freon12.pdf and the documented CLI commands, then verify that malformed or empty tokens produce a non-zero invalid-page-number error while valid page selections still work.

Written by the indexing model from the issue text.