frontend: Warn before deleting protected namespaces

[Anjali-Chauhan1]

Summary

This PR adds a UI safeguard against accidentally deleting Kubernetes system namespaces. Headlamp previously showed Delete and Force Delete for every namespace — including default, kube-system, kube-node-lease, and kube-public — so a user with a cluster-admin token could break a cluster with a single accidental click. These namespaces are now treated as protected: the delete dialog shows a warning and requires typing the namespace name to confirm.

Related Issue

Fixes #6064

Changes

• Added Namespace.PROTECTED_NAMESPACES and an isProtected() helper in lib/k8s/namespace.ts, matched against the kubernetes.io/metadata.name label (falling back to the object name).
• Updated DeleteButton to show a warning Alert and a type-the-name confirmation field, keeping the Delete button disabled until the name matches, for protected namespaces.
• Updated DeleteMultipleButton to flag any protected namespaces in a multi-select deletion.
• Minor ConfirmDialog change to support the disabled-confirm state.
• Fixed dark-theme contrast so the warning text/border is readable (warning Alert previously rendered near-invisible in dark mode).
• Added unit tests for isProtected() and new Storybook stories + snapshots (ProtectedNamespace, NonProtectedNamespace).
• Added the new i18n string to the translation catalogs.

Steps to Test

1. Open a cluster and navigate to Namespaces.
2. Click delete on a system namespace (e.g. kube-system). Observe the warning "This is a system namespace. Deleting it may break your cluster." and that Delete stays disabled until you type the namespace name.
3. Click delete on a regular namespace (e.g. my-app). Observe the standard single-confirmation flow with no warning.
4. Multi-select several namespaces including a system one and delete. Observe the warning that the selection includes system namespaces.
5. Switch to dark theme and repeat step 2 — confirm the warning box and text are clearly visible.

Screenshots

Notes for the Reviewer

• Protection is purely a UI guard / first line of defense; the API server is still the source of truth.
• This touches the i18n layer — only the English string is filled in; the other locale catalogs get the empty key for translators.
• The dark-theme fix is applied per-component (explicit warning.mainon the Alert) rather than changing the shared theme, because palette.warning.light is intentionally reused as a translucent background tint elsewhere (PluginSettingsDetails).

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Anjali-Chauhan1
Once this PR has been reviewed and has the lgtm label, please assign joaquimrocha for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mahesh-09-12]

@Anjali-Chauhan1 took a look at the namespace safeguards and the changes around deletion behavior. The checks added here appear consistent with the expected restrictions, and the confirmation prompt is applied appropriately across the affected actions. I didn't spot any issues in the code paths modified by this update.