feat(ui): populate parameter dropdowns dynamically from Kubernetes resources (dynamic `enum`)

# Summary

What change needs making?

Today, `enum` on a workflow parameter is a **static list** baked into the manifest:

```yaml
arguments:
parameters:
- name: target-namespace
value: "namespaceA"
enum: ["namespaceA", "namespaceB", "namespaceC"]
```

I'd like a way to declare that the list of allowed values should be **resolved from live
Kubernetes resources** when the Submit form is rendered, so operators pick from what
actually exists on the cluster instead of a hand-maintained list.

Strawman API — a new `enumFrom` alongside the existing `enum`:

```yaml
arguments:
parameters:
- name: target-namespace
enumFrom:
resource:
apiVersion: v1
kind: Namespace
jsonPath: "{.metadata.name}" # value to use for each item
labelSelector: "appspace=test" # optional filter

- name: target-deployment
enumFrom:
resource:
apiVersion: apps/v1
kind: Deployment
namespace: "{{workflow.parameters.target-namespace}}" # cascading (see below)
jsonPath: "{.metadata.name}"
```

Design notes / things I'd expect to be contentious:

- **RBAC must be the submitting user's, not the controller's.** Resolution should happen in
the Argo **Server**, using the caller's credentials (SSO token / SA), so the dropdown can
never disclose the existence of resources the user isn't allowed to see. This is the part
I'd most want maintainer input on.
- **UI affordance, not a security control.** The resolved list should not be treated as
server-side validation of submitted values — a user who can submit a workflow can already
supply arbitrary parameter values. It's about discoverability and typo-avoidance.
- **Graceful degradation.** If resolution fails (RBAC denied, CRD absent, API timeout), the
field should fall back to a free-text input with a visible warning rather than blocking
submission.
- **Load.** Resolution only on form render, with a short server-side cache and a cap on
returned items, to avoid hammering the API server for large clusters.
- **Cascading dropdowns** (namespace → deployments *in that namespace*) are the real prize
but clearly harder, since the form must re-resolve when an upstream field changes. Happy
for that to be a phase 2 — even non-cascading, cluster-scoped lists (namespaces, cluster
workflow templates, storage classes) would be a big win on their own.

## Use Cases

When would you use this?

We run a `ClusterWorkflowTemplate` that restarts a specific workload at a scheduled
date/time, with parameters for `target-namespace`, `target-kind` and `target-name`.
Operators submit it from the UI.

The names of deployments and namespaces are exactly the kind of thing that changes
constantly, so today we have two bad options:

1. **Hardcode the `enum`** — we do this in another template, and it carries this comment:

```yaml
# Namespace → App mapping (Argo UI does not support
# conditional dropdowns, so all apps are listed.
# Pick the namespace that matches the chosen app.)
```

The list goes stale the moment someone adds a service, and it can't express
"these deployments belong to that namespace", so the UI offers invalid combinations.

2. **Leave it as free text** — which is what we ended up doing, and it means typos are only
caught once the workflow runs. For a *scheduled* workflow that's genuinely painful: a
mistyped deployment name sits in a suspended node all night and fails at 03:30, having
restarted nothing. We've had to add a pre-flight validation step whose entire job is to
fail fast and print the valid options into the logs — a workaround for a dropdown we
can't build.

Other cases that would benefit:

- Picking a PVC / Secret / ConfigMap to operate on.
- Picking a target `ClusterWorkflowTemplate` or `WorkflowTemplate` for a dispatcher workflow.
- Any self-service / operator-facing workflow where the audience is not the person who
wrote the manifest, which is where the UI's Submit form is most valuable.

---

**Message from the maintainers**:

Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.

The issue names the Submit form, Argo Server, Kubernetes resources, and the existing static enum as starting surfaces; trace how enum values reach the form and how requests are authorized. Resolve the RBAC, fallback, caching, item-cap, and cascading-scope questions with maintainers before implementation. Done means an agreed phase-one behavior is documented and the live-resource dropdown avoids exposing unauthorized resources, with free-text fallback when resolution fails.

Written by the indexing model from the issue text.