Feat/add gitlab mr approval controls

[Joseph94m]

Closes #413
Closes #414

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

[thomasboni]

@Joseph94m Reviewed + tested e2e. Also checked legacy fidelity line-by-line against the backend2 controls. All of this by Claude. I've verified its results.

Blocker

1. An approval rule with an empty name is invisible to ISSUE-502. MRApprovalRule.Name is serialized with json:"name,omitempty" (internal/ir/pipeline.go), and mr_approval_rules_min_approvals.rego references rule.name bare in the message sprintf and the ruleName data field. When the key is absent the whole deny body is undefined, so no finding is emitted. Reproduced end to end: a rule {id: 99, name: "", rule_type: "any_approver", approvals_required: 0, applies_to_all_protected_branches: true} with minimumRequiredApprovals: 2 yields status: passed, zero issues. The same rule with a name is flagged. GitLab API-created and auto-created rules can carry empty names, so this is a realistic silent false negative on exactly the violation class the control exists for. Fix: object.get(rule, "name", "") in the rego (and/or drop the omitempty), plus the unnamed-rule case in policies/rules_test.go. Identity keys on approvalRuleId, so the fix re-keys nothing.
2. gitlab/dataCollectionGitlabProtection.go classifies 403/404 by substring on the error string, and this PR makes that drive MRApprovalRulesKnown and a user-visible status. The error string embeds the request URL, so a project whose ID contains "403"/"404" returning a 500 gets misclassified as premium-missing (safe direction, Known=false, but a hard failure is silently downgraded). Prefer the typed response status code.
3. The config key renames the platform's minimumRequiredApprovalAllProtectedBranches to minimumRequiredApprovals and the mapping is recorded nowhere (FINGERPRINT.md covers the identity correction only). Write it down for the platform migration.
4. Same terminal-rendering gap as Feat/add gitlab variables controls #422: on a 403 the JSON says error but the report shows both controls as a bare green check under "Passed Controls". Needs the caveat stat line (one shared fix for both PRs).
5. There is still one not-resolved Claude code comment review in the PR

Nits

• enabled: true without minimumRequiredApprovals is a silent no-op (rego defaults the minimum to 0). Matches legacy and is documented, but a config-load warning would save users from a control that can never fire.
• Collector/IR comments say non-premium yields 403/404 while the rego/defaultConfig comments say Free returns 200-empty; both paths are handled, harmonize the wording.
• Docs say "401/403"; a genuine 401 actually aborts the whole protection collection (outcome still safe via nil ProtectionData).
• 404 branch of the tolerance is untested (403 is covered, same path, cheap to add).
• Init wizard: MRApprovalMinCount is unvalidated free text; "0" produces an enabled no-op, non-numeric silently falls back.

[Joseph94m]

@thomasboni should be good !