Strict parsing tests: `matlab` 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: matlab

• Lexical family: line_exclusive
• Extensions: .m, .mlx
• 48 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.

Known ambiguity patterns to check for this language

• bitwise_ops vs closures: already found in Rust (|a| a + 1 miscounted as bitwise-OR) and C++ (std::cout << miscounted as a bitwise shift) -- check whether this language reuses a bitwise operator token for closures/streams too.
• explicit_casts vs pointers: already found in C (cast syntax overlapping pointer-asterisk repetition) -- check for the same overlap if this language has explicit unsafe casting.
• test vs regex_execution: already found in TypeScript (myRegex.test('x') miscounted as a test-framework call) -- check for the same collision if this language has a .test(-style regex method.

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

Phase 1: Logic Topology & Structure

• branch -- Control flow that forces a decision or jump: if, else, switch, for, while, catch, try, &&, ||, ternary.
• args -- Parameter blocks of functions, methods, and lambdas. Must safely step over type hints and generics without ReDoS.
• structural_boundaries -- Keywords defining structural boundaries and straight-line execution: var, return, class, import.
• func_start -- Exact syntax anchoring the start of an executable block of logic: method signatures, constructors.
• class_start -- The syntax defining an object-oriented class, struct, or record.

Phase 2: Safety & Execution Risk

• safety -- Defensive programming constructs that prevent crashes at runtime: try/catch, explicit null checks, guard.
• safety_bypasses -- Syntax that actively bypasses type safety, swallows errors, or relies on unpredictable state: force unwrapping (!), any, raw memory casting, linter bypasses (@ts-ignore).
• high_risk_execution -- Process-killing commands and catastrophic runtime vulnerabilities: eval, exec, process.exit.
• io -- Interaction with disk, network, or external systems: file reading/writing, HTTP clients, sockets.
• api -- Code exposed to the outside world. Captures explicit visibility markers (export, public) AND implicit architectural defaults for implicitly-public languages (Python, Fortran).
• state_mutation -- Reassignment of variables or modifying collections: let, mut, volatile, .push(), .set().
• dead_code -- Commented-out structural code and unused logic trails: // if (x), /* var y */.
• doc -- Structured documentation meant to be parsed by IDEs or generators: JSDoc, docstrings.
• test -- Assertions and unit testing framework keywords: describe, it, assert, expect.

Phase 3: Architecture & Domain Sensors

• concurrency -- Asynchronous logic and parallel execution: async, await, Promise, Thread.
• ui_framework -- DOM manipulation and UI components: HTML tags, React hooks.
• closures -- Anonymous functions, lambdas, inline callbacks: fat arrows (=>).
• globals -- Accessing global state, environment variables, or system registries: window., process.env.
• decorators -- Annotations applied to classes/methods: @Injectable, [Obsolete].
• comprehensions -- Collection iterators or inline looping: .map(, .filter(.
• scientific -- Math, data science, and complex rendering libraries: Math., numpy.
• reflection_metaprogramming -- Metaprogramming, reflection, and dynamic property assignment: Reflection, Proxy, .bind().
• import -- Dependency resolution and module loading (import, require, using), plus the paired capture-group rule that extracts the exact dependency path string for the dependency graph.
• ownership -- Authorship metadata: @author, Created by:.

Phase 4: Specialized Sub-systems

• planned_debt -- Annotated future work: TODO, WIP, STUB.
• fragile_debt -- Explicit admissions of fragile or dangerous logic: HACK, FIXME, XXX.
• spec_exposure -- Audit tags establishing traceability of intent: [SPEC-123], [audit].
• ssr_boundaries -- Server-Side Rendering computation boundaries: getServerSideProps.
• events -- Event-driven architecture signatures and message brokers: emit, EventEmitter, Kafka.
• pointers -- Explicit tracking of raw memory addressing and pointer dereferencing: *const, &mut, IntPtr.
• memory_alloc -- Explicit unmanaged memory allocations and raw heap manipulations: malloc, new.

Phase 5: Resource Management & Stability

• telemetry -- Structured logging and observability frameworks.
• debug_prints -- Ad-hoc, temporary debug statements: print(, console.log(.
• explicit_casts -- Explicitly bypassing the compiler's type-checker: as String, (int), static_cast.
• panics_and_aborts -- Forcefully destroying the current execution context: throw, raise, panic!, abort().
• thread_sleeps -- Thread blocking or forced timeouts: sleep(, delay(.
• bitwise_ops -- Bitwise operations manipulating raw bytes.
• sync_locks -- Explicitly coordinating threaded logic to prevent race conditions.
• immutability_locks -- Explicitly locking data so it cannot be mutated: const, final, readonly.
• cleanup -- Explicitly destroying state or releasing resources: free(, dispose(), .close().
• encapsulation -- Explicitly hiding logic from the rest of the application: private, protected, internal.
• listeners -- Waiting to receive state from an external broadcast: on(, addEventListener, subscribe(.
• test_skip -- Bypassed tests or ignored verification specs: @ignore, test.skip(.

Hybrid Domain Sensors

• serialization_parsing -- JSON, XML, YAML parsing libraries.
• regex_execution -- Native regex evaluation commands.
• time_date_logic -- Time/date instantiation and math.
• ipc_rpc_bridges -- Inter-process or RPC bridging commands.

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.