Harden code_quality.yml against same-repo-PR secret exfiltration via MSBuild/restore

[kploch]

Split out from PR #190 review (codeant-ai, qodo-code-review).

Problem

.github/workflows/code_quality.yml's qodana job now guards against fork PRs (empty secrets), but a same-repository (non-fork) pull_request still runs with QODANA_TOKEN and GH_PACKAGES_TOKEN available. A branch in this repo can add an MSBuild target that runs during the Qodana restore/build phase and exfiltrate either credential before human review.

Accepted for now

Opening a same-repo PR already requires write access to this repository — the same access level that could already push directly to a branch and trigger build-dotnet.yml's restore with the same GH_PACKAGES_TOKEN-scoped feed. So this doesn't expand the trust boundary of the repo, it's consistent with the existing threat model, and it mirrors ploch-common's already-working, unmodified qodana_code_quality.yml.

Options for a real fix

1. Move to pull_request_target with the workflow run pinned to the base ref and an explicit approval gate before checking out/building the PR head — more invasive, needs careful design to avoid reintroducing the same class of risk.
2. Require a label (e.g. safe-to-scan) applied by a maintainer before this job runs for external/first-time contributors.
3. Rotate QODANA_TOKEN/GH_PACKAGES_TOKEN to environment-scoped secrets requiring approval (GitHub Environments + required reviewers).
4. Accept the status quo permanently and close as won't-fix, matching ploch-common.

Refs #151