Derive expression from name for internal compliance controls

What does this MR do and why?

The GraphQL API required callers to submit expression when adding a compliance requirement control, even though the only value the server accepts is derived from the control's name. Callers had no way to know that value in advance.

The issue proposed deleting that presence validation. This commit didn't proceed with it, as other code depends on expression being present, so the model cannot allow a null through. Deleting the check would also disable the two remaining expression validations on this write path, because validate_expression_schema and validate_expression_matches_control both return early when expression is blank. There is no database constraint to fall back on either, since the column is nullable, so the model validation is the only check standing in the way.

Instead, a model callback derives expression from name for internal controls when the caller omits it, reading from the same source the existing match validation already checks against. The presence validation stays in place as a backstop, so control names with no predefined expression still fail loudly instead of reaching the database in an unevaluatable state.

Changelog: fixed

EE: true

References

#597862 (closed)

How to test

This fails on master, but succeeds on this branch:

mutation {
  createComplianceRequirement(input: {
    complianceFrameworkId: "gid://gitlab/ComplianceManagement::Framework/1"
    controls: [{ name: "default_branch_protected" }]
    params: { name: "Test requirement", description: "Test" }
  }) {
    errors
    requirement { id name }
  }
}

On master, this returns the "Expression can't be blank" error. With this change, it creates the requirement and control successfully, with the expression derived from default_branch_protected.

10 new spec examples were added across model, service, and GraphQL request specs, and each was confirmed to fail if the new callback is disabled. RuboCop is clean. The GraphQL reference docs and locale/gitlab.pot were regenerated.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #597862 (closed)