fix: detect case-insensitive output stem collisions

## Problem

On case-insensitive filesystems, two input files whose stems differ only by letter case are accepted as distinct even though they map to the same output directory. Processing the second file replaces the first file's artifacts.

This affects current `main` at `c6478aae9ab50a13fc54c0599a0a459396c15b99` and release `0.0.5`.

## Reproduction

On Windows:

```powershell
New-Item -ItemType Directory a, b
Copy-Item tests/fixtures/normal.pdf a/Report.pdf
Copy-Item tests/fixtures/normal.pdf b/report.pdf
hi-pdf-parser parse a/Report.pdf b/report.pdf --out out
```

Both inputs emit success envelopes and the command exits successfully, but `out/Report` and `out/report` identify the same filesystem directory. Only the artifacts and manifest from the second input remain.

## Expected behavior

The existing stem-collision validation should reject input sets that resolve to the same output directory on the current platform, including case-only collisions on case-insensitive filesystems.

## Root cause

`collect_input_paths()` keys its `seen` mapping with the original `path.stem`. Python string comparison is case-sensitive even when the target filesystem is not.

## Impact

A valid multi-file CLI invocation can silently discard previously generated output on Windows and other case-insensitive platforms.

## Suggested implementation

Normalize the collision key using the platform's path-case rules while preserving the original stem in diagnostics and output naming. Add a focused regression test for case-only stems on a case-insensitive platform.

Start at collect_input_paths(), where collision keys use the original path.stem, and trace the existing stem-collision validation. Reproduce the case-only Report.pdf/report.pdf invocation on a case-insensitive platform, then add a focused regression test confirming the input set is rejected while original stems remain available for diagnostics and output naming.

Written by the indexing model from the issue text.