Simplify CI job architecture for Go linting

What does this MR do?

Simplifies the CI pipeline:

• Renames the code_quality job to go:lint for clarity of purpose and consistency with shell:lint and dockerfile:lint.
• Renames gl-code-quality-report.json to gl-golangci-lint-report.json.
• Enables hard failure for the go:lint job (i.e., removes allow_failure: true), ensuring code quality standards are strictly enforced.
• Removes the static QA CI job, which is now redundant since go:lint fails hard.

Why was this MR needed?

Previously, allow_failure: true was used to allow the code_quality job to fail "softly" (i.e., fail with warning) if the linter flagged issues, and the downstream static QA job handled gating the pipeline success based on the code_quality report's contents.

allow_failure: true was used to ensure the report is always uploaded (so MR annotations appear), but artifacts: when: always handles that independently of job success.

By removing allow_failure: true for code_quality (now called go:lint), there is no need for static QA.

What's the best way to test this MR?

Inspect the CI pipeline and observe that static QA is no longer present.

What are the relevant issue numbers?

N/A