Fix false-green JSON validation in shared Super-Linter config

[IldarMinaev]

Problem

The shared Super-Linter configuration enables JSON validation, but its custom ESLint configuration matches JavaScript and TypeScript only. Super-Linter therefore detects a changed malformed JSON file, reports that no matching configuration exists, and still completes run-lint successfully.

This false-green result was reproduced during the Renovate automerge negative-path pilot. It makes run-lint unsuitable as a required merge gate for consumers that expect JSON syntax validation.

Proposed outcome

• Add regression fixtures that run the supported Super-Linter version with the shared configuration: malformed JSON must fail, valid JSON must pass, and existing JavaScript and TypeScript behavior must remain green.
• Restore narrowly scoped validation for **/*.json by using the supported Super-Linter JSON configuration or an equivalent shared ESLint configuration.
• Keep JSONC and JSON5 behavior unchanged unless a separate policy approves them.
• Fail the regression test if a file type enabled by shared policy is silently ignored because no matching configuration exists.
• Verify the central fix on representative direct consumers and on a public fork pull request.
• Inventory local ESLint overrides and different Super-Linter pins; create project follow-ups only for consumers that cannot inherit the shared fix.
• Document the validation contract used by required CI gates.

Acceptance criteria

• The exact shared configuration fails on a malformed JSON fixture.
• Valid JSON and existing JavaScript and TypeScript fixtures pass.
• The JSON fixture is linted rather than reported as ignored.
• A representative consumer receives a failed run-lint check for malformed JSON.
• The same negative path works for a public fork pull request without secrets or elevated permissions.
• Every consumer exception has a linked project issue or pull request.

Related work

• Problem epic and evidence: Prevent false-green Super-Linter checks across Netcracker repositories qubership-monitoring-operator#496
• Renovate automerge rollout: Roll out safe and efficient Renovate automerge across observability repositories qubership-monitoring-operator#499
• Negative-path pilot: Verify negative paths for Renovate automerge qubership-ai-packages#79

This issue changes shared lint behavior only. Renovate policy, repository rulesets, and unrelated file-format validation remain outside its scope.

[IldarMinaev]

The consumer inventory for the current observability rollout scope is complete:

• All 32 repositories run Super-Linter and consume the shared Netcracker/.github linter configuration.
• All 32 contain tracked JSON files, 316 files in total.
• Thirty repositories pin v8.7.0. qubership-profiler-agent pins v8.6.0, and qubership-graylog-plugins-init pins v8.1.0; the regression suite should verify these versions or the consumers should be upgraded before rollout.
• Twenty-nine repositories have no local .github/linters/eslint.config.mjs and can inherit a central fix.
• Three repositories preserve local overrides with cp --update=none: qubership-graphite-remote-adapter, qubership-logging-operator, and qubership-graylog-obfuscation-plugin. None of those configurations matches JSON, so each needs a repository follow-up after the central behavior is defined.
• No repository in this scope has a general changed-file JSON syntax gate independent of Super-Linter. Some specific files receive indirect validation from Renovate, npm, Docker resolvers, or application tests, but arbitrary JSON remains uncovered.

The minimal central contract should restore only **/*.json, preserve existing JavaScript and TypeScript behavior, and assert that malformed JSON fails without an ignored-file warning. Enabling VALIDATE_JSON_PRETTIER would couple syntax validation to formatting policy and would leave the documented VALIDATE_JSON contract false.

[IldarMinaev]

The organization-wide consumer inventory is now complete for active repositories that copy Netcracker/.github/config/linters in their Super-Linter workflow.

• 139 nonarchived repositories consume the shared linter directory.
• 59 pin Super-Linter v8.7.0, 6 pin v8.6.0, 14 pin v8.5.0, 2 pin v8.2.1, and 20 pin v8.1.0. One repository pins v8.4.0. These 102 v8 consumers load eslint.config.mjs.
• 35 pin v7.3.0 and 2 pin v7.4.0. Super-Linter v7 looks for .eslintrc.yml, not eslint.config.mjs, so these 37 consumers retain the image's built-in JSON configuration and do not consume this central ESLint file.
• Four v8.7.0 repositories preserve a local .github/linters/eslint.config.mjs: qubership-workflow-hub, qubership-graphite-remote-adapter, qubership-logging-operator, and qubership-graylog-obfuscation-plugin. None of those local files matches JSON. The central file can directly fix the other 98 v8 consumers; these four need follow-ups.

The official template changes its JSON implementation between v8.5.0 and v8.6.0. Versions v8.1.0 through v8.5.0 use jsonc-eslint-parser with FlatCompat; v8.6.0 and v8.7.0 use the flat configs exported by eslint-plugin-jsonc. A central block copied from only the v8.7.0 template therefore needs exact-image compatibility tests before rollout.

A narrower compatibility candidate is to use import * as jsoncParser from "jsonc-eslint-parser" and add only a files: ["**/*.json"] parser block with jsonSyntax: "JSON". Direct ESLint runs in the exact v8.1.0, v8.5.0, v8.6.0, and v8.7.0 slim images confirmed that valid JSON exits 0 and malformed JSON exits 1 with a parsing error. A default import is not portable: it works in v8.1.0 but v8.7.0 has no default export and exits 2 while loading the config. The official v8.2.1 and v8.4.0 templates use the same older parser API, but their exact images should remain in the committed regression matrix. The v7.3.0 and v7.4.0 built-in defaults also need malformed/valid JSON smoke tests because the central eslint.config.mjs does not govern them.

This inventory adds one exception outside the initial rollout scope: qubership-workflow-hub. I did not create a project issue for it; it should be linked once the central contract is approved.

[borislavr]

Tested in separate repository for
super-linter/super-inter@v8.1.0: https://github.com/MyBorislavrOrg/liner-test/actions/runs/32477784768
super-linter/super-inter@v8.7.0: https://github.com/MyBorislavrOrg/liner-test/actions/runs/32475323523