Feat/add gitlab mr approval settings control

[Joseph94m]

Needs #423

Closes #415
Cloes #416

[thomasboni]

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

Blockers

1. StatusFor has no branch for mergeRequestSettingsMustBeCompliant, producing a false pass. Reproduced e2e: a non-403/404 error on the approval-rules endpoint aborts the protection collection, ProtectionData stays nil, and the JSON reports mrSettingsResult: "passed" with exit 0 while ISSUE-503 correctly reports error on the same run. The control never saw any data. Add the same guard as the 503 branch: ProtectionData == nil || ProtectionData.MRSettings == nil => StatusError, before the CI-file checks (this control is CI-file independent too).
2. The shipped default config breaks the "unset = not checked" contract. defaultConfig/.plumber.yaml ships all 8 ISSUE-506 expectations and the 503 surface populated. Any user config with extends: plumber:default (the normal path) that enables the control inherits every one of those opinions and cannot unset them (an overlay can override a value, not remove it). Reproduced e2e: with only mergeMethod/squashOption/trains/pipelines/removeSourceBranch configured, the run still flagged resolveOutdatedDiffDiscussions, which I never set. Issues Migrate platform control: MR approval settings must be compliant (ISSUE-503) #415/Migrate platform control: MR settings must be compliant (ISSUE-506) #416 specify "a setting left unset is not checked". Fix: comment out the per-field expectations in the shipped default (keep enabled: false and the docs), so enabling the control enforces only what the operator explicitly sets.
3. control/mrcomment.go writeIssueDetails is missing all four MR controls. Neither mergeRequestApprovalSettingsMustBeCompliant / mergeRequestSettingsMustBeCompliant (this PR) nor mergeRequestApprovalRulesMustRequireMinimumApprovals / ...MustCoverAllProtectedBranches (Feat/add gitlab mr approval controls #423, slipped through that review too) are in the hand-written order list, so their findings are silently dropped from the MR comment body (the control shows failed with zero detail lines). Same bug class as the Feat/add gitlab variables controls #422 fix. Since this branch is stacked on Feat/add gitlab mr approval controls #423, adding all four here works.
4. Conflicts should be resolved and branch rebased

Should fix

• Terminal caveat for an unreadable approvals listing. On the 403 run, ISSUE-503 shows as a bare green check under "Passed Controls" (and counts toward the score) while JSON says error. Feat/add gitlab mr approval controls #423's fix round added approvalRulesUnreadableCaveat for exactly this; after the rebase, reuse it (or a sibling) for the 503 stat-builder case.

[Joseph94m]

@thomasboni should be good!