Migrate deprecated orange background tokens to semantic

What does this MR do and why?

Replace the deprecated gl-bg-orange-50 and gl-bg-orange-100 utility classes with their value-identical semantic tokens gl-bg-feedback-warning and gl-bg-status-warning. The rendered color is unchanged in both light and dark themes, so this is the warning-background slice (Phase 1) of the deprecated-color migration.

Coupled test selectors are updated alongside the markup and constants. The remaining gl-bg-orange-50 in the operations dashboard project spec is a stale selector for a component already migrated to feedback tokens and is left for the red/danger batch, which edits the same assertion line.

Related to #601899

Before / After

No visual change: the replacement produces 0 differing pixels out of 9,728,000, and the two renders are byte-identical (same SHA-256).

All 11 touched surfaces were rendered against the real compiled app/assets/builds/tailwind.css plus the @gitlab/ui design tokens, in light and dark, with the class attribute as the only difference between the two pages.

Before — gl-bg-orange-50 / gl-bg-orange-100

After — gl-bg-feedback-warning / gl-bg-status-warning

Computed colors and pixel diff

Why the two spellings resolve to the same color, dark mode included

The deprecated utility is not a raw palette pin — it already flips per theme, which is exactly why the swap is safe:

• gl-bg-orange-50 → --orange-50 → --gl-color-orange-50 (light) / --gl-color-orange-900 (dark)

• gl-bg-feedback-warning → --gl-feedback-warning-background-color → those same two entries

• gl-bg-orange-100 → --orange-100 → --gl-color-orange-100 (light) / --gl-color-orange-800 (dark)

• gl-bg-status-warning → --gl-status-warning-background-color → those same two entries

Measured with getComputedStyle against the real built CSS:

• 50 pair: #fdf0d5 light, #5d220d dark — identical on both sides
• 100 pair: #fada9c light, #7d2d0e dark — identical on both sides

Surfaces covered: saved-view subscription limit warning, saved-view create dropdown warning, comment field warning footer, snippet "hidden" badge and pill, admin database diagnostics schema card, custom admin roles security recommendation, commit list footer, invite-members warning token, settings search highlight, and the MR widget warning row.

Method: both pages re-rendered with every label stripped so the swapped class is the only difference, screenshotted at 1280×1900 CSS px at 2× device scale, then diffed — bounding box None, max channel delta 0.

This is a CSS-level reproduction rather than a screenshot of a running GDK. Every change here is a background-only utility swap with no component-level overrides, so the class → token → value resolution is the same path the app takes.

How to set up and validate locally

1. Run the updated frontend specs, for example:

   yarn jest spec/frontend/work_items/list/components/work_items_create_saved_view_dropdown_spec.js spec/frontend/work_items/list/components/work_items_existing_saved_views_modal_spec.js

2. Spot-check a warning surface (the invite-members warning token, a snippet "hidden" badge, or the commit list footer) and confirm the background color is unchanged.

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 #601899