test/goroot: match vareq recovery diagnostics

[cpunion]

Depends on #2222.

This narrowly scopes the extra parser-recovery diagnostics emitted for test/syntax/vareq.go to its exact primary diagnostic, source line, and location. Independent one-use groups preserve unrelated same-line diagnostics and do not consume duplicate follow-ons more than once.

Validation:

• go test ./test/goroot -run "TestCheckExpectedErrorsScopesVareqRecovery|TestAdditionalParserRecoveryDiagnosticsFailOpen" -count=1
• go test ./test/goroot -count=1
• test/syntax/vareq.go with Go 1.24.11, 1.25.0, 1.26.0, and 1.26.5
• remaining compile/errorcheck xfails with the same four GOROOT versions
• git diff --check

[fennoai]

Review summary

Test-harness-only change scoping parser-recovery diagnostic pairing for the GOROOT errorcheck runner (test/goroot/runner_test.go, runner_unit_test.go, xfail.yaml). Reviewed for correctness, security, performance, and documentation accuracy across all four dimensions.

No blocking issues found. The change is well-structured and unusually well-tested — the fail-open behavior, one-use group consumption, physical-source gating, and line-directive detection each have targeted unit coverage.

Verified as correct (no action needed):

• parserRecoverySourceCode handles // GC_ERRORAUTO correctly via the // GC_ERROR prefix (runner_test.go:1763).
• hasLineDirective line-vs-block asymmetry (column-0 //line vs inline /*line) matches Go's directive semantics (runner_test.go:1778).
• parserRecoveryAuthorized correctly limits one source to one recovery group per matched ERROR (runner_test.go:1179).
• physicalDiagnosticSources aggregation (physical = previous && physical) is conservatively correct for repeated files (runner_test.go:1140).
• diagnosticPathResolver.resolve rejects ambiguous short paths and unknown absolute paths (runner_test.go:1641).
• xfail.yaml reason removals correspond to cases now handled (bug050, vareq1, bug228, chan1, issue11610, vareq).

Minor (optional) observation:

• test/goroot/runner_test.go:1739 — in parserRecoverySecondaryGroups, parserRecoverySourceCode(source) runs again here even though the preceding parserRecoverySourceSecondaries(primary, source) call already normalizes internally (:1696). It's idempotent, so there's no correctness impact; normalizing once up front (and passing the cleaned value down) would remove the double work and make the data flow clearer. Non-blocking.