fix(syntax): implement Hy's string prefixes, shebang and bracket strings

[takeokunn]

Hy string prefixes were unimplemented across the board — f"…", r"…", b"…", rb"…", t"…". The atom scanner ran past the opening quote and stopped at a delimiter inside the literal, so r"a)b" closed its enclosing list early. f-strings are one instance of this, not the whole bug — it accounts for 417 of 469 baseline parse failures.

Two more, both silent:

• #! shebangs not stripped — 393 files parsed at exit 0 with the shebang as two junk atoms.
• Bracket strings #[[…]] parsed as code — #[[(defn evil [] 1)]] yielded a real defn node inside a raw string. That's the shape where a lint rule fires on text that isn't code. #[delim[…]delim] was silent too, not a loud failure as my brief claimed.

Measured against HEAD, with Hy itself as oracle

Same code, both sides, 2824 readable files:

	HEAD	merged
parse failures	493	116
files we refuse that Hy accepts	308	15

378 newly parse, 1 newly fails — and that one is a true positive: real Hy refuses it too (LexException: invalid string prefix). It previously "passed" only because the f-string was never scanned. Every failure class strictly decreased; none went up. All 15 remaining over-refusals already failed at HEAD with byte-identical errors, so there are zero new over-refusals.

f-strings are one opaque atom, deliberately

read_fcomponent calls parse_one_form, so interpolations are arbitrary code and finding the closing quote needs a sub-reader — f"{(str "}")}" is legal, as are f"{f"{x}"}" and f"{#[[raw]]}".

But ExpressionKind is only Root/List/Atom, so interleaved text-and-forms needs a new node kind rippling through the formatter, edit engine and every rule — and children are editable, so the formatter would reindent inside the literal segments between interpolations. Exposing them trades the #[[…]] silent-corruption class for a new one. Blind beats wrong, and today the whole file is invisible.

A surprise worth recording: format specs are nearly unreachable. : is not in NON_IDENT, so f"{x:>10}" interpolates the symbol x:>10, and f"{x:>{width}}" is a LexException. You need f"{x :>10}".

~ deliberately excluded, though it was implemented and measured

Several formatter paths opened a child list without writing that child's prefixes, so a prefixed list was emitted with its prefix deleted. Making ~ a prefix aimed that at the most common construct in Hy macro code: edit format newly changed the meaning of 14 files. PR #100 has since fixed that family, so ~ is the obvious next step; hy_unquote_is_not_yet_a_reader_prefix pins the known-wrong reading so whoever does it finds the reasoning.

Other dialects: 42,142 file-parses, zero differences

Full-tree hash pre- vs post-change across carp/clojure/commonlisp/emacslisp/fennel/janet/lfe/racket/scheme plus all 21,071 under the permissive Unknown reader. A unit test pins has_prefixed_strings/has_bracket_strings false and #[[a]] as a list for all ten.

Rebase: resolved arm by arm, not by side

This crossed #96, #98 and #100, all of which edit the same files. The classify_reader_macro match Dialect table is the dangerous one — base had the group Unknown | Lfe | Hy | Carp; #98 pulled Lfe out and this change pulls Hy out, so each side's group line still named the other's dialect. Taking either side would have silently deleted a dialect's reader support with every gate still green.

A 29-case probe confirms every recent PR's behaviour survives: Janet's ' prefix, Clojure's spaced #:ns {…}, LFE's #B(/#M(/#S(/#"…"/#\(/|foo bar|, and #100's MissingReaderForm on (a ') across five dialects — plus non-leakage checks that f"a b" in Common Lisp is still four children.

One probe assertion of mine was wrong and got corrected rather than papered over: I'd asserted a later-line #! is refused; it isn't, and the branch's own test documents that it keeps its pre-existing reading.

One pre-existing issue found, not touched

13 of the 15 remaining over-refusals are the ,-as-Unquote divergence colliding with #100. Hy's empty tuple is written (,), and a trailing , before } is common; with , read as a reader prefix, #100 turns those into a hard MissingReaderForm. classify_hy's comment says , "occurs at a token start essentially never" — the corpus says 13 files, including hylang/simalq, kanaka/mal and Hy's own contrib/walk.hy. Live on main today, not a merge defect, but the comment's claim is measurably too strong.

Verification

cargo build --workspace, cargo test --workspace (152 suites), cargo test --test cli, cargo fmt --all --check, cargo clippy --all-targets --all-features -- -D warnings — all exit 0. All four prior PRs' own tests ran and passed by name. No golden or pinned count moved.