Section ID not flagged when it contains invalid characters

[chrispcampbell]

I ran into a case where someone included a "%" character in a section ID, like section:foo_50_%_bar, but this was not caught by the parser like it should have been, and it was passed through like a normal comment.

We should fix the parser so that it correctly validates section IDs.

[chrispcampbell]

I delegated this one to Claude, summary below.

The bug

Section (and def) IDs were being validated at parse.ts:181-189, but the
validation was unreachable for certain inputs. The outer command regex captured
the ID with (\w+)?, which matches only [A-Za-z0-9_]. On
section:foo_50_%_bar, that capture stopped at the %, and then the trailing
\s*--> couldn't match — so the entire regex failed, parseCommand
returned undefined, and the comment was silently treated as an ordinary HTML
comment. The section command was dropped with no error, which is why it caused
problems downstream.

The fix

parse.ts:176: changed the ID capture from (\w+)? to (\S+)? so any invalid
character (like %) is still captured into m[3] and then caught by the
existing strict validation ^[a-z0-9]+(?:_+[a-z0-9]+)*$, which throws the clear
"must contain only lowercase letters, digits, and underscores" error. This
covers def, begin-def, and section alike since they share this parser.

Added a regression test in parse.spec.ts for the exact section:foo_50_%_bar
case. Full suite (15 tests) passes.

Remaining edge case (not addressed)

An ID with a literal space (e.g. section:foo bar) still fails the outer
match and is silently ignored, since \S+ stops at whitespace. That's a rarer
case and handling it well would mean reworking how commands are distinguished
from plain comments.