feat(controls): add projectMustHaveSecurityPolicySource (ISSUE-601, GitLab Ultimate) and renumber workflowsMustHaveExplicitName to ISSUE-422 for site parity

[Joseph94m]

Closes #417

[thomasboni]

@Joseph94m Reviewed + tested e2e by Claude (real binary against a mock GitLab GraphQL/REST API)

Blockers

1. A GraphQL project: null response is treated as an authoritative "nothing linked" and fires a false Critical. GetSecurityPolicyProject returns (nil, true, nil) when respData.Project == nil, but a null project on HTTP 200 is GitLab's signature for "this token cannot see the project via GraphQL" (the exact case Feat/add gitlab variables controls #422 handles with ErrProjectVariablesUnreadable). Reproduced e2e: null project => securityPolicyProjectResult: "failed" with a Critical "no GitLab security policy project is linked" finding, exit 1, on a project whose linkage was never actually read. Fix: respData.Project == nil => known=false (not-evaluable); only a present project with a null securityPolicyProject field means "none linked".
2. control/mrcomment.go writeIssueDetails does not list projectMustHaveSecurityPolicySource, so ISSUE-601 findings are silently dropped from the MR comment body (control shows failed with zero detail lines). Same class as the Feat/add gitlab variables controls #422 must-fix.
3. A transport/network failure on the GraphQL read yields a silent exit-0 run. Reproduced e2e (connection reset): status error in JSON but exit 0 and dataCollectionDegraded unset. The variables control (Feat/add gitlab variables controls #422 fix round) marks the run degraded (exit 3) on network errors with a carve-out prefix so unrelated controls stay clean; this fetch should follow the same pattern so CI gates can tell a transient blip from a clean pass.
4. Evaluability is coupled to the earlier protection fetches (the resolved review-bot thread, still true in code): with only this control enabled and a token that cannot list branches, FetchProjectBranchData aborts the collection before the GraphQL read ever runs, and ISSUE-601 reports not-evaluable forever (reproduced e2e with a 403 on branches). Either run the security-policy read before the fatal fetches (populating it even when the collection later errors) or document the token requirements next to the control.

Nits

• codes.go: the const block commented "workflow-hygiene controls (6xx)". But it seems to me that issues 6xx have nothing to do with it. Verify and fix any inconsistency in issues numbering.
• Root .plumber.yaml adds a documented but empty projectMustHaveSecurityPolicySource: key (null section). Harmless today, but either give it its fields commented out or drop the key.
• Commit message typo: "Update controls doc ot make it more precise".