Selection: reject expressions the grammar can't fully consume (#121)

[vv137]

Fixes #121.

The bug

Selection::parse returned parseOr() without checking the input was
consumed, so anything the grammar didn't understand at the end of an expression
was dropped in silence:

:color red chain A resi 5     " coloured ALL of chain A, reported success, exit 0
:count (chain A               " unbalanced paren accepted
:count chain A OR chain B     " OR isn't an operator; the tail vanished

The first is the shape that matters. A missing operator produced a
plausible-looking wrong figure that survives visual review. Every
silent-truncation bug in this layer — #116 included — reached the user through
that one missing check.

The fix

The parser reports a leftover token or an unclosed paren through an optional
out-param. Enforcement is central rather than per-command, and — this is the
part I got wrong on the first pass — it fails closed:

• Application::parseSelection and forEachInScope return an empty
  selection on a parse error, so a malformed expression stops before the
  mutation rather than being announced after it. Every consumer already guards
  on emptiness.
• CommandRegistry::execute turns a recorded error into a failed command, so
  no handler — present or future — can forget to check.

Why fail-closed matters, using the sharpest case:

# before this correction: reported the error AND still carved the object
$ :extract chain A resi 5 as carved
Bad selection: unexpected 'resi' in selection    # ...but `carved` now exists,
                                                 # and the source lost 6 atoms

Errors are scoped to a command's own expressions. Dispatch nests — :run and
the control-flow commands execute their body through the same path — so the
slot is taken on the way in and handed back on the way out. Without that, a
child's bad selection replaced :run's "2 commands, 1 failed" summary,
destroying the file:line context issue #80 built.

Two selection paths don't go through command dispatch and needed their own
check: the :foreach VAR in <sel> header (used to iterate the prefix silently
at exit 0) and interactive / search (silent, and it left the error to be
blamed on the next command).

A second bug the check found

pepseq H.L was matching every histidine. readWord() stops at the
documented . / ? wildcards, so the pattern reached matchPepSeq as bare
"H" — the matcher has understood both all along. Now pepseq H.V ==
pepseq H?V == pepseq HLV.

Verification

No false positives, checked two ways: the 59-expression corpus and a sweep of
every selection expression in the docs and lib/ recipes both parse clean, and
corpus results stay byte-identical to the pre-#116 baseline. All nine malformed
cases from the issue are rejected with the offending token named. 307 selection
assertions and 46 script assertions green, including regression tests for
fail-closed :extract, un-poisoned $sele, nested :run attribution, and the
:foreach header.

Deliberately not in this PR

:color red not heliix still colours everything at exit 0 — an unknown
keyword produces no leftover token, so the end-of-input check cannot see it.
It looks like a one-liner but isn't: that same fall-through is how cross-object
dispatch works (1crn parsed against 1ubq legitimately yields empty until the
right object comes round), so distinguishing a typo from a non-matching object
name needs the multi-object loop's cooperation. Filing separately with that
analysis rather than guessing at it here.

🤖 Generated with Claude Code