Remove access to iframed cluster driver UI in preparation for Ember removal

[rak-phillip]

Is your feature request related to a problem? Please describe.
The dashboard still uses Ember UI components for some cluster drivers. There appear to be 4 with UI built into Ember: 'tencentkubernetesengine', 'huaweicontainercloudengine', 'oraclecontainerengine', and 'linodekubernetesengine'

Additionally, cluster drivers can specify a url from which to load custom (Ember) ui.

These UI's have been deprecated since 2.11 and we should consider how to remove them. We should also consider updating the warning shown on the cluster driver page:

Support for UI Plugins (based on Ember) for cluster and node drivers was deprecated in Rancher 2.11.0 and will be removed in a future release. These need to be migrated to the new UI Extensions framework.

Describe the solution you'd like
We will need to deal with the cluster driver cards in the provisioning create page, the cluster driver create page, and the cluster driver list.

Some options:

• grey out the cluster driver's card in the provisioning create page OR

• remove the cluster driver's card from the provisioning create page

• only show the warning banner about UI deprecation when we detect a cluster driver with an Ember ui extension has been enabled

• update the cluster driver table to indicate to users which drivers have (dashboard) ui extensions

• remove the 'custom ui url' input from both cluster and node driver create pages

Describe alternatives you've considered

Additional context
Once this is done, remaining references to the Ember UI can be removed from the backend: rancher/rancher#54039

[github-actions]

🤖 Issue grooming questions

The problem statement and technical context are well described — thank you! To finish grooming this issue, the following primary criterion needs clarification:

Missing: Acceptance Criteria

The issue currently lists several possible approaches (greying out cards, removing cards, updating warnings, removing the custom UI URL input) but doesn't commit to a specific set of changes. Could you define concrete, testable acceptance criteria for this issue? For example:

1. What should happen to cluster driver cards in the provisioning create page for drivers with Ember UI? (Grey out? Remove entirely?)
2. Should the 'Custom UI URL' input be removed from both cluster and node driver create/edit pages?
3. What should the updated deprecation warning look like and when should it be shown?

A checklist of "done" criteria would help scope the work clearly for an engineer picking this up.

This comment was generated automatically to help gather the information needed to groom this issue.

Generated by Daily Issue Grooming Aw