fix(base64-rs): print usage instead of blocking on console stdin

Running base64 with no FILE fell into the stdin branch and sat in a read
loop. That is exactly what GNU does, but on Windows it presents as a dead
terminal: the console echoes keystrokes so it looks like a prompt, output
buffers into 32K chunks so nothing comes back as you type, and there is no
hint that it is waiting for Ctrl+Z.

Guard the implicit case only. With no FILE operand and stdin attached to a
console, print the help text to stderr and exit 1. Pipes and '<' redirects
are untouched, so pipelines and the parity harness see no change -- the
harness always hands the child a stdin pipe via input=. An explicit '-'
still reads the console for anyone who does want to type input by hand.

Uses std::io::IsTerminal, so the crate stays dependency-free.

base64-rs/README.md

@@ -61,6 +61,7 @@ Verified against GNU coreutils 9.7 with a 154-case differential test ([tests/par
 | | Why |
 |---|---|
 | `\r` is skipped when decoding, as `\n` already is | GNU rejects CRLF input as invalid. On Windows a base64 file will routinely have CRLF line endings, and erroring on those would make the tool useless for its main job. Everything else is still rejected unless you pass `-i`. |
+| Running it with no FILE at an interactive console prints the usage text and exits `1` | GNU would read stdin, which looks exactly like a hung terminal — no prompt, no output, no hint that it wants Ctrl+Z. Only applies when stdin is a console: pipes and `<` redirects read stdin as usual, and `base64 -` still reads the console if you actually want to type input. |
 | `--help` omits GNU's support URLs | This isn't GNU coreutils; pointing at their bug tracker would be wrong. |
 | Error messages quote with `'ASCII'` | GNU uses `'…'` in a UTF-8 locale. Windows consoles are frequently cp437/cp1252, where those bytes render as mojibake. |