Add the scan profile advanced configuration variable catalog

What does this MR do and why?

Replaces the empty variableDefinitionsFor stub in variable_definitions.js with the real per-scan-type configuration variable catalog. Each variable entry includes a label, description, valueType (boolean/enum/string/stringList), optional options for enum types, and the corresponding CI/CD envVar name. The catalog mirrors the GraphQL input types (SecretDetectionConfigurationInputType and SastConfigurationInputType) and the Ruby source of truth in Security::ScanProfiles::Configuration::CiVariables::MAPPINGS. Variables like secureAnalyzersPrefix that share the same envVar across scan types stay shared, while imageSuffix and excludedPaths remain scan-type-specific since they map to different CI/CD variable names per type.

Restores the value-entry UI in add_scan_profile_variable_modal.vue: radio groups for boolean/enum values, text input for strings, textarea for string lists, and the Apply to all enabled triggers checkbox with per-trigger override fields. Also restores buildEditableConfigurationRows and its helper buildProfileRows in utils.js, which generate the advanced-configuration table rows from the current edit-form state. This wiring connects the modal's existingSettings to <advanced-configuration-editor> so users cannot add a variable that's already configured, completing the UI flow that was deferred from MR1 while the catalog was a stub.

Also fixes a data-loss bug flagged in review on MR1: scan_profile_drawer.vue's saveEdit only sends triggerConfigurations to the update mutation when triggersChanged is true, but that flag only compared the set of enabled trigger types, so a config-only edit (adding a variable without also toggling a trigger) was silently dropped. triggersChanged in scan_profile_edit_form.vue now also compares the current triggerConfigurations against the value read from the profile, so a configuration-only change is caught too. This was deferred from MR1 since it had no way to happen while the catalog was empty; now that a variable can actually be added, it's reachable.

Follow-up planned, not done here: the envVar mapping in this catalog is hardcoded and duplicates Security::ScanProfiles::Configuration::CiVariables::MAPPINGS. !257393 (merged) will expose that mapping via GraphQL (Group.securityScanProfileVariables), but it isn't merged yet, and #627250 (whether label/description/valueType should also move to the backend) is still unresolved. Tracked in #630693, to be picked up once both land.

References

• issue: [Frontend] Scan profile drawer: view, create, e... (#624191 - closed)
• parent work item: Advanced Configuration Profiles for Security Sc... (gitlab-org#20193)
• follow-up: Switch scan profile variable env-var mapping to... (#630693)
• Design: security-inventory-profiles

Screenshots or screen recordings

Before	After
	The values are being sent to the BE (Still not saving in the UI).
	After selecting a value, it will be excluded from the list.

How to set up and validate locally

1. Enable the feature flag on a Rails console: Feature.enable(:custom_scan_profiles_ui).
2. Open the group's Security Configuration page and click Manage profiles on the Secret Detection or SAST row.
3. Create a new profile or edit an existing one, and enable a configurable trigger (Merge request pipeline or Default branch pipeline).
4. Click Add variable. The picker now lists the real catalog of variables for that scan type, each showing its label, CI/CD env var badge, and description.
5. Pick a boolean variable (for example Historic scan). Confirm the Enabled/Disabled radio group appears, and Add variable stays disabled until a value is picked.
6. Click the modal's Add variable button to add the variable to your in-progress edit form. Reopen Add variable and confirm the variable no longer appears in the picker — existingSettings excludes it while you're still editing the form.
7. Pick a string-list variable (for example Paths to exclude) and enter multiple lines in the textarea. Click the modal's Add variable button, then confirm each non-empty line is now a separate entry in the edit form.
8. Click the form's Save changes (or Create profile) button. Close and reopen the profile, then open Add variable again. Confirm both variables are still excluded from the picker — this proves they persisted to the backend. (There's no visible list of added variables yet — that UI is deferred to the next MR.)
9. With more than one configurable trigger enabled, pick a variable and uncheck Apply to all enabled triggers. Confirm a value field appears per trigger, and saving only includes the triggers given a value.

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.