ci(regressions): restore column-aware SARIF comparison after byte→UTF-16 transition

[robertohuertasm-datadog]

Context

PR #914 changed the static-analysis kernel from emitting 1-based UTF-8 byte columns to 1-based UTF-16 code-unit columns (matching LSP, VS Code, and the SARIF v2.1 default encoding).

While that PR was open, the regression workflow (.github/scripts/check-regressions.js) compared two SARIF runs as JSON strings:

• before = analyzer built from main → byte columns
• after = analyzer built from the PR branch → UTF-16 columns

For every violation on a line containing a non-ASCII character, the column numbers drift by N (where N is the number of multibyte characters before the violation position). The string-equality comparison saw those as "violation X removed" + "violation Y added" pairs, even though the rule, the file, and the line were identical.

Example from numpy/_core/tests/test_strings.py line 1284:

("λ" * 5 + "μ" * 2, "μ"),

Build	startColumn	endColumn
main (byte cols)	14	32
#914 (UTF-16 cols)	14	31

→ same violation, two different rows in the diff.

To unblock #914's CI, commit 329df0cc temporarily dropped startColumn / endColumn from both the comparison key and the summary location string, comparing by (file, ruleId, message, startLine, endLine) instead. That commit was explicitly marked as a one-shot loosening and called out a stacked follow-up PR to restore the original behaviour. This is that follow-up.

What this PR does

• Restores the comparison key to the full physicalLocation (including startColumn and endColumn).
• Restores the summary table location string to its original startLine:startColumn-endLine:endColumn format.
• Effectively reverts the JS-only change introduced in 329df0cc. No other files touched.

Why this is safe to land

Once #914 is merged into main, both sides of the regression check run with UTF-16 columns:

• before = main (post-fix(kernel): emit 1-based UTF-16 code-unit columns from tree-sitter nodes #914) → UTF-16 columns
• after = any feature branch → UTF-16 columns

…so column-aware diffing becomes meaningful again and the false "removed + added" pairs disappear. Verified locally on _core/tests/test_strings.py:

Comparison logic	"Removed" diffs	"Added" diffs
Column-aware (this PR) on main-vs-main baselines	0	0

Merge order

This PR depends on #914 landing first. It is opened against the rob/fix/tree-sitter-byte-column-bug-IDE-6037 branch as a stacked PR — GitHub will automatically retarget it to main once #914 is merged.

What we get back

Column-level regression detection, on top of the file / rule / line / message protection we kept throughout. The workflow can again catch column-shift bugs introduced by future tree-sitter or grammar updates, off-by-one regressions in rule code, etc.

Closes IDE-6037 follow-up.

[datadog-prod-us1-6]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 85.45% (+0.00%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0c391ff | Docs | Datadog PR Page | Give us feedback!}

[robertohuertasm-datadog]

• ci(regressions): restore column-aware SARIF comparison after byte→UTF-16 transition #915 👈 (View in Graphite)
• fix(kernel): emit 1-based UTF-16 code-unit columns from tree-sitter nodes #914
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.