Add Dependency Firewall rule descriptions

What does this MR do and why?

Improves the Dependency Firewall policy editor UI ahead of a customer demo. Removes the info box that appeared below the Malicious package rule and replaces it with a short, one-line description at the top of every rule card.

Changes:

• Removed the alert box from Malicious package rules that explained deny-only behavior.
• Added a one-line description above each rule type (License, Vulnerability, Malicious package, Risk severity), positioned above configuration options.
• License rule's top description now flips to "Allow..." instead of "Deny..." for legacy allow-list rules, since the old wording was backwards for that case.
• Updated/added Jest specs for the dependency_firewall rule builder components.
• Regenerated locale/gitlab.pot for new and changed translatable strings.

An earlier version of this MR also added hover "?" icons carrying extra caveats for the malicious, license, and risk severity rules. Those were removed after reviewing the actual UI — each rule now shows only its one-line description, nothing else.

Wording review from idurham: switched every rule description from indicative to imperative mood ("Denies..." → "Deny...", "Allows..." → "Allow..."), reworded the risk severity description to avoid an ambiguous phrase GitLabDuo flagged, lowercased the license dropdown's item-type-name to match every other dropdown in this app, and simplified the exceptions placeholder text.

Also fixed a pre-existing bug (unrelated to the description work, found while testing): editing a rule's exceptions field would lose focus and reset the cursor to the end mid-typing. Root cause: the live YAML editor echoes back its own programmatic value updates, and that echo was being re-parsed as a genuine edit, which regenerated every rule's id and broke the :key-based Vue diffing that keeps each rule card mounted while you edit it. Confirmed present on origin/master too, not something introduced by this MR's own changes.

fromYaml/addIdsToPolicy are shared across every policy type, so I checked for blast radius: pipeline_execution and vulnerability_management's editor components already guard against this exact bug via an areManifestsEqual() check; Dependency Firewall's editor never adopted that pattern, so it's the one that was actually affected. Switched DFW's fix to match that same established pattern for consistency. Verified manually in the browser: existing (already-saved) DFW and approval policies both still load and edit correctly, and the full security_orchestration Jest suite (3149 tests across every policy type) passes with no regressions.

All frontend Jest specs pass (178/178). No ESLint or Prettier issues.

A follow-up commit reverted the earlier defensive change to the shared addIdsToPolicy helper in utils.js, since the areManifestsEqual() guard alone prevents the echo, and left utils.js untouched to match the established pattern exactly.

References

Closes https://gitlab.com/gitlab-org/gitlab/-/work_items/630379

Screenshots or screen recordings

Before	After	Rule
		License
		Malware
		Risk severity (needs FF enabled)
		Vulnerability

How to set up and validate locally

1. Enable the dependency_firewall_phase2 feature flag if not already on: run Feature.enable(:dependency_firewall_phase2) in bin/rails console.
2. Also enable dependency_firewall_risk_severity_rule to see the Risk severity rule type: Feature.enable(:dependency_firewall_risk_severity_rule).
3. Visit a project's dependency firewall policy editor, e.g. http://gdk.test:3000/<group>/<project>/-/security/policies/new?type=dependency_firewall.
4. Add a License rule and confirm it shows the description "Deny packages based on the selected software license." above its configuration options.
5. Add a Vulnerability rule and confirm it shows the description "Allow or deny packages with vulnerabilities at or above a specified severity level."
6. Add a Malicious package rule and confirm it shows the description "Deny packages flagged as malicious by GitLab."
7. Add a Risk severity rule and confirm it shows the description "Deny packages that exceed a specified number of vulnerabilities."
8. Load an existing legacy License allow-list rule and confirm the description reads "Allow packages based on the selected software license." instead of "Deny...".
9. In any rule's exceptions field, type a comma-separated list (e.g. npm123,foo456) including mid-string edits, and confirm the field never loses focus or resets the cursor.

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.