fix(ci): csp-scan hangs at a terminal instead of printing its usage

[forkwright]

Fixes a live regression on main, found by an independent adversarial review of PR #171 after it merged.

The defect

ci/csp-scan.py's stdin fallback — added to keep a large file set from hitting the argv size limit — iterates sys.stdin whenever argv is empty. A closed or piped stdin reaches EOF and falls through to the usage error. A live terminal never does, so a bare interactive invocation blocks forever instead of exiting 2.

Reproduced under an allocated pty: no output, still running.

Why it read as safe

The comment justifying the absence of an isatty() gate said an empty or closed stdin "falls through to an empty paths list either way." That is true for closed stdin and false for a tty — the comment's own account of the mechanism was wrong, which is exactly what made the code look correct. It now states what it actually relies on.

The stdin path is unchanged. It stays, because it is the reason this exists.

Why CI was green on a script that hangs

Nothing in CI ever invokes it from a terminal. Every cheap way to test the empty case — closed stdin, /dev/null, an empty pipe — reaches EOF immediately and passes against the broken code. So the new ci/check-csp-scan-selftest.py allocates a real pty, and pins all three input paths:

• bare at a tty → exit 2 with usage, within a timeout
• piped path list → still consumed (the argv-limit path must not be swallowed by the gate)
• empty pipe → still a usage error

It is discovered automatically by the derived fixture runner from #170; no wiring line.

Verification

Mutation: disabling the gate (elif False:) makes the selftest report did not exit within 10s -- it is blocking on a stdin read instead of printing usage and return 1, rather than hanging the suite. Restored, and the selftest returns 0.

Shape worth noting

This is a fix for an input-handling defect that introduced a new input-handling defect in the same guard path — the "claim does not match runtime behaviour" class that issue #92 was opened to eliminate. Credit to the reviewer who caught it by running the thing under a pty rather than reading the diff.