Feat/add gitlab variables controls

[Joseph94m]

Closes #412
Closes #418

Test on https://gitlab.com/getplumber/examples/go-test-with-hash @thomasboni

[thomasboni]

@Joseph94m Reviewed + tested e2e by Claude, then I verified its results:

What works

• Exact expected findings on a 6-variable matrix (unprotected, unmasked, short-value, file-type, env-scoped, hidden). File-type exclusion from the masked rule and the short-unmaskable-value decision are both implemented and documented.
• GraphQL cursor pagination: a variable on page 3 is flagged.
• No value leak: sentinel values planted in the API responses appear nowhere in JSON, SARIF, stdout or stderr. ir.SettingsVariable has no Value field, VariablesData is json:"-".
• 401/403 and project: null correctly yield status: error in JSON, never a false pass. The pointer-struct change killing the old "null decodes as empty list" silent pass is right.
• Identity fields exactly variableName/variableType/environment, fingerprints pinned. Default-disabled but visible as "disabled in configuration". Gate exits 1 on findings.

Blockers

1. False "pass" in the terminal report when the listing is unreadable. On a 401/403/null-project run the JSON says error, but the human report lists both controls under "Passed Controls" as a bare green check, with score 100/100 and Status: PASSED. That is exactly the success-on-incomplete-data footgun the renderPassedControlsSummary comment warns about, and branchMustBeProtected already solves it with a warning caveat stat line. The new stat builders in cmd/render_details.go (buildGitLabControlStats, the two new cases) should emit that caveat when result.VariablesData == nil || !result.VariablesData.Known.
2. MR comment shows the control failed with zero detail lines. control/mrcomment.go writeIssueDetails iterates a hand-written order list of control names; neither cicdVariablesMustBeProtected nor cicdVariablesMustBeMasked was added, so ISSUE-201/202 findings are silently dropped from the MR comment body.
3. A transient network failure on the variables fetch degrades the run (exit 3, correct) but flips every unrelated CI-file control to error (reproduced e2e: image collection succeeded, then a connection reset on the variables call turned dockerInDockerResult, imageAuthorizedSourcesResult, etc. into error). Branch protection has a degraded-reason carve-out for exactly this (degradedReasonBranchProtectionPrefix in control/degraded.go); the variables reason needs the same classifier.

Nits (should be done too)

• Root .plumber.yaml: both new blocks say "Ships disabled" directly above enabled: true (the root file enabling them is fine, the copied narrative is not).
• Missing # === separator line above the "CI/CD variables must be masked" title in both .plumber.yaml files.
• control/task.go: "Checking CI/CD variables" reuses progress step 9, same as branch protection.
• Stats show only the findings count; "Variables Checked: N" would give a denominator like the comparable controls.
• The GraphQL query still fetches value on the settings-control path (needed only by image resolution). Never persisted (verified), but blanking Value in CollectGitlabVariables or using a value-free query would harden it.
• Test gaps: no multi-page cursor test, and no task-level test pinning that a 401 does not mark the run degraded.

[Joseph94m]

@thomasboni should be better