Refine OAuth consent warnings and device anti-phishing

What does this MR do and why?

Follow-up to !240906 (merged) (device/regular OAuth consent consistency), part of work item 539182.

Correctly adding the app-trust block to the device confirm page surfaced a warning-fatigue problem: an admin authorizing an untrusted app stacked three same-weight cautions, so none stood out. The same latent problem existed on the regular consent page. This MR shows at most one salient warning alert, scaled to actual risk, and keeps neutral app metadata in the info-well.

Applied to both consent surfaces (doorkeeper/authorizations/new and the device index/authorize views):

• Render the app-trust warning as a Pajamas variant: :warning alert (matching the admin warning) instead of info-well warning text, and drop it entirely for GitLab-provided apps (.com only).
• Fold trust into a single admin-escalation warning; the info-well holds only neutral metadata (provenance, owner, created).
• Keep an always-present anti-phishing line on the device flow in every case (trusted included). This is a deliberate exception to "make device identical to the regular page": app-trust gives zero protection against device-code phishing (attacker starts a device flow with a trusted client_id and phishes the victim to enter the attacker's user_code), so the reminder is the sole defense exactly when the app-trust warning is absent. Copy is split per page to match the user's current action.
• Fix the device heading grammar ("Authorize a device to access your GitLab account.").

Also carries the smaller review cleanups: extract the shared clickjacking pointer-events guard to a partial, associate the id-less device-code input with its label (a11y), gl-mx-auto, drop a dead gl-items-center wrapper, tighten the confirm-page id assertion, and add feature coverage for the device confirm page rendered from a real grant.

References

• First step: !240906 (merged)
• Work item: #539182 (closed)

Screenshots or screen recordings

Tight crops of the consent card. "Before" is current master (post-!240906 (merged)); "After" is this MR. The trusted-app row is stubbed to Gitlab.com? since it renders only on GitLab.com.

Light mode

State	Before	After
Regular consent - non-admin, untrusted
Regular consent - admin, untrusted
Device flow - enter code
Device confirm - non-admin, untrusted
Device confirm - admin, untrusted
Device confirm - trusted app (GitLab.com)

Dark mode

State	Before	After
Regular consent - non-admin, untrusted
Regular consent - admin, untrusted
Device flow - enter code
Device confirm - non-admin, untrusted
Device confirm - admin, untrusted
Device confirm - trusted app (GitLab.com)

How to set up and validate locally

1. Create an OAuth application (User settings → Applications) with a redirect URI and the read_user scope; note its Application ID.
2. Regular consent page - visit: /oauth/authorize?client_id=<APP_ID>&redirect_uri=<REDIRECT_URI>&response_type=code&scope=read_user&state=test
   • As a non-admin: expect one warning alert ("Make sure you trust ..."), scopes accordion, and the info-well with owner/created only.
   • As an admin: expect the single combined admin-escalation warning (trust folded in) and no separate trust alert.
3. Device flow - visit /oauth/device, enter any code:
   • Entry page shows "Never enter a code someone else gave you."; confirm page shows "Only authorize if you started this yourself." - present in every case.
   • Same one-warning admin/non-admin behavior as above on the confirm page.
4. Trusted-app path (no warning + "provided by GitLab") only renders on GitLab.com; locally you always get the untrusted branch.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.