fix: name the word to quote when a path command name meets =

[tobert]

Two error paths from the literal-word stack answered with an internal token name instead of the fix.

A command name that cannot start an assignment now reports glued words and names the word to quote. The command parser hands an adjacent = to assignment parsing so x=1 stays an assignment, but only an identifier can start an assignment lvalue; for a path name the deferral went to a parser that could never apply, so the glued-word diagnosis never ran. The filter now fires only for an identifier name.

./bin=1          # names ./bin=1, was "found './bin' expected 'NEWLINE', 'set', ..."
2026/report=1    # names 2026/report=1 — never reached the message, on any release
x=1              # still an assignment

Reporting the right message exposed the wrong span: it named 1, not ./bin=1. A bare = was not a glue-candidate unit, so word/=/word never formed one run, and a run had to begin at or after the grammar's error position while the rejection reports at the run's last fragment. An = between two adjacent words now joins the run, and a run qualifies when it reaches that position.

Home-relative assignments accept a dash-number path. DashNumWord was the one word token missing from the tilde-split suffix list.

p=~10-20
p=~2024-01-02

Across a hundred probed inputs the only parse-result changes are those two; everything else differs in error text alone. The CHANGELOG entries for the four merged layers are reordered to read in the order the changes build.

Validation: 6,712 tests pass, clippy across all targets with warnings denied, rustdoc with warnings denied, kernel tests without default features. The new cases fail against the current main and pass here; the pre-existing cases in both suites pass either way.

Reviewed through kaibo, GLM-5.2 with DeepSeek V4 Flash investigation.

🤖 Generated with Claude Code