Guard device OAuth confirm and unify admin warning

What does this MR do and why?

Follow-up to !246419 (merged), addressing two questions raised in review there.

• Bug fix: Oauth::DeviceAuthorizationsController#confirm rendered the authorize/confirm page for any submitted user_code, including invalid, blank, expired, or already-consumed ones. Users saw the admin escalation warning and a working "Confirm" button for a grant that matched nothing. confirm now returns doorkeeper's own error response (authorization_error_response(:invalid_user_code) or (:expired_user_code)) when the device grant is missing or expired, redirecting back to the device code entry page with a flash error instead.
• Maintenance/copy consolidation: the admin-escalation warning existed as two near-duplicate translated strings across the regular OAuth consent, device OAuth, and IAM consent screens. Since confirm now guarantees a real grant, the device authorize page always has an application, making its nameless fallback string and @application nil-guards dead code. Removed both and unified all three screens onto a single parameterized string that keeps the interpolated, bolded client name. Removed the two orphaned strings from locale/gitlab.pot.

References

• !246419 (merged)

How to set up and validate locally

1. Sign in as an administrator.
2. Visit /oauth/device.
3. Enter a random or invalid code and submit. Confirm you are redirected back to the code entry page with an error, instead of seeing a confirm page with the admin warning and a "Confirm" button.
4. Create an OAuth application, then start a real device grant (or use the regular OAuth consent flow at /oauth/authorize).
5. Confirm the admin escalation warning names the application, using the same wording across the device, regular, and IAM consent screens.

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.