fix(cli): a bad input path is a message, not a traceback

[hchittanuru3]

Found by installing postflight from PyPI into a clean venv and using it the way someone encountering it for the first time would.

Two ordinary mistakes produced full stack traces:

$ python -m postflight --otel /tmp/typo.jsonl
Traceback (most recent call last):
  ...
  File ".../adapters/otel.py", line 206, in turns_from_jsonl
    with open(path, encoding="utf-8") as handle:
FileNotFoundError: ...

$ python -m postflight --otel notes.txt
  ...
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Neither answers the question, and both tell the user the tool crashed, which is untrue. Now:

cannot read /tmp/typo.jsonl: No such file or directory
notes.txt is not newline-delimited JSON: Expecting value: line 1 column 1 (char 0) (expected one exported span object per line)

Both pinned by tests. The argparse error for a missing source and the Langfuse credentials check were already clean; these were the two paths that were not.

The rest of the fresh-install audit passed

• Installs on 3.12 and 3.14 from both wheel and sdist, pulling zero dependencies (pip list shows only pip and postflight)
• mypy --strict passes against the public API and catches a deliberate type error in it, which is the real test of py.typed: a missing marker would have made mypy skip the package silently
• The README's Turn example, typed verbatim, produces the documented TOOL_REFUSAL + UNVERIFIED_CLAIM pairing
• CLI, --coverage, and --json all behave, with exit 1 on a fault