semantic-check: fail fast on a tty instead of hanging on stdin

[Ar9av]

Summary

A bare prismor semantic-check on an interactive terminal hangs. Reported as "semantic-check shows an error."

text = args.text; if not text: text = sys.stdin.read() — with no argument (or an empty-string argument, which is falsy) it falls through to sys.stdin.read(), which blocks until EOF. On a real terminal with nobody piping input, the command just sits there with no prompt and no hint; the only way out is Ctrl-D, which then prints error: no text provided. Either way it reads as the tool being broken.

Proven with a real pty (no input sent):

OLD: HUNG — still waiting on stdin after 5.0s
NEW: errored fast in 0.3s

Fix

Guard the stdin fallback with sys.stdin.isatty() — the same pattern prismor unlock already uses. When stdin is a terminal and no text was passed, print usage and exit 1 immediately:

$ prismor semantic-check
error: no text provided
  pass it as an argument:  prismor semantic-check "<text>"
  or pipe it via stdin:     echo "<text>" | prismor semantic-check

Piping (echo … | prismor semantic-check) and the positional-argument path are unchanged.

Testing

• New pty regression test: a bare invocation on a tty errors fast, never hangs (would hit subprocess.TimeoutExpired against the old code).
• Fast-error path for empty piped stdin.
• Both in tests/test_cli.py; verified on st3ve that piped/arg invocations still analyze normally.