Strict parsing tests: `nix` structural signatures

[squid-protocol]

Update: the lexical-delimiter checklist item originally in this issue (_line_anchor/_inline_comment/_block_start/_block_end) has been removed -- those 4 rule keys are dead config, never read anywhere in gitgalaxy/ (confirmed via grep -rn across the whole package). The real comment-stripping engine (prism.py's _strip_segment_comments) dispatches purely on lexical_family against a separate family-level table in gitgalaxy_config.py. See the epic (#518) for the new issue tracking that real gap instead.

---

Part of #518.

Language: nix

• Lexical family: line_exclusive
• Extensions: .nix
• 0 of the baseline structural signatures are defined (non-None) for this language in gitgalaxy/standards/language_standards.py.

Reference

gitgalaxy/standards/how_to_add_a_language.md is the canonical doc for what each signature is supposed to capture/exclude, the 5 lexical parsing families, and (recently added) the AI/ML and literate-programming extension packs. Read the INCLUDES/EXCLUDES wording there for any signature before writing its test -- the one-line descriptions below are a quick-reference copy, not the full spec.

A rule being None here is not a gap

Only write tests for the checklist below. If a signature isn't in this language's rules dict, or is explicitly None, that's an intentional "doesn't apply to this language" per the doc's Strict Feature Parity rule (#4) -- don't invent a synthetic match for it just to have a test.

Lexical family note: This language's lexical family is line_exclusive -- there is no native multi-line block syntax; confirm the engine correctly ignores stray closing tokens rather than treating them as real block terminators.

Checklist (this language's non-None structural signatures)

Test template

For each checked signature: (1) a positive-match test against its documented includes, capturing exact group text where applicable; (2) a negative-match test against its documented excludes; (3) any cross-rule ambiguity check flagged above; (4) a ReDoS immunity test (reuse assert_redos_immune from tests/core_engine/test_language_standards_strict.py) sized to this rule's actual quantifiers. Group multiple signatures that share the same simple pattern into one parametrized test rather than writing near-duplicates -- don't force one test per key if several are trivially similar for this language.

New tests land in tests/core_engine/test_language_standards_strict.py, the existing home for this style of test.