[Bug]: Suppression scanners misclassify shell conditional regex operands

[ben-ranford]

Summary

The suppression scanners treat parentheses inside a shell conditional regex operand as grouping operators. A literal hash after a regex group is therefore misclassified as a comment and may make valid code fail for missing suppression metadata.

Review evidence: #1650 (comment).

Reproduction steps

Run this source using a shell that supports the extended conditional and regex operator, then check the source with the tracker using build.bash:

[[ "foo#nolint" =~ (foo)#nolint ]]
printf '%s' "$?"

Expected behavior

The regex matches, so the output is0. The second hash is literal regex text and requires no suppression metadata. Actual comments after the conditional still require metadata.

Actual behavior

The tracker hasInlineSuppressionMarker returns true for the first line. It treats regex parentheses as ordinary grouping and exposes the following hash. The review identifies the same classification in the local and trusted workflow scanners; verify all-three parity during the fix.

Logs and output

/bin/bash: parse0, run0, stdout0
/bin/sh:   parse0, run0, stdout0
/bin/zsh:  parse0, run0, stdout0
tracker expected marker: false
tracker actual marker: true

These are the bundled macOS interpreters. In particular, this sh result does not establish POSIX sh portability or support in other sh implementations.

Proposed scope and acceptance criteria

Targetv1.9.0, medium conditional/regex lexical-state work. Distinguishing extended conditional operands and regex grouping requires grammar separate from PR1650's shell operator, substitution and case-boundary correction. The seven-language cases in #1644 cover JavaScript regex literals, not this shell conditional grammar.

• Define supported shell dialects and versions for extended conditionals and the =~ operand.
• Recognize only eligible unquoted [[, ]], and =~ tokens; quoted/escaped tokens and ordinary command arguments must not enter regex state.
• Treat regex grouping/nested parentheses, alternation, bracket expressions and attached hashes as operand text only in that recognized context.
• Define quoted, partially quoted and escaped regex behavior and operand termination according to the chosen shell grammar.
• Cover logical conditional operators, nested grouping, backslash-newline, multiline expressions and full-file state before changed hunks.
• Keep ==, !=, numeric and file-test conditional operators as negative controls; they must not acquire regex rules.
• Cover command, parameter and arithmetic substitutions within the regex operand.
• Detect real adjacent comments after closing conditionals or subsequent shell operators; preserve ordinary shell grouping and case comments outside regex operands.
• Preserve command/arithmetic/parameter expansion suffixes and quoted/embedded hash controls.
• Keep tracker, local checker and trusted workflow verifier consistent, with exact source, metadata and fingerprint assertions.
• Add bounded runtime/version oracles and failing-before/passing-after regressions; do not mask every parenthesis or the entire conditional indiscriminately.

Version / commit

ed664c2.

Environment

macOS with bundled Bash/sh/zsh and Node.js. Local parser/execution probes and exported tracker marker detection; no external writes during reproduction.