E2E workspace-name fallback can resolve an unrelated DevWorkspace #23993

Describe the bug

ApiUrlResolver.resolveWorkspaceName() can resolve a missing workspace name to a different DevWorkspace whose Kubernetes resource name merely starts with the requested name plus a hyphen. The fallback accepts any nonempty alphanumeric suffix. TestWorkspaceUtil.stopWorkspaceByName() and deleteWorkspaceByName() use the resulting URL, so cleanup can stop or delete the wrong workspace.

Steps to reproduce

1. Ensure there is no DevWorkspace with metadata.name: workspace.
2. Have a separate DevWorkspace with metadata.name: workspace-2 and display-name label kubernetes.io/metadata.name: workspace-2.
3. Call getWorkspaceApiUrl('workspace') (or stopWorkspaceByName('workspace')).

Actual: the resolver returns the API URL for workspace-2.

Expected: the resolver reports that workspace was not found. A restored resource such as workspace-4fnq should remain resolvable when its display-name label is workspace.

Code references

• Prefix fallback in ApiUrlResolver.ts
• Stop/delete callers in TestWorkspaceUtil.ts

Why it matters

A name collision during E2E cleanup can act on a workspace other than the one the test requested. Checking the DevWorkspace display-name label before accepting a generated-name fallback would preserve backup-restore support while avoiding this case.

Related: #23911 introduced the suffix fallback for backup restore; #23965 added an exact-name check against the list.