Add UI binding flow

[cnvergence]

Summary

Adds the ability to bind Kubernetes services from a provider to a consumer cluster entirely through the
web UI, without requiring the CLI.

After selecting a template and clicking "Bind", users see a modal with three setup options:

• Provide Kubeconfig — Paste a consumer cluster kubeconfig, and the backend automatically deploys the konnector, creating the binding bundle on the consumer.
• APIServiceBindingBundle — Copy a pre-generated YAML manifest to apply manually on the consumer.
• Manual CLI — Old flow with kubectl bind command.

"View Details" on a resource card now opens a details modal that shows resources, permission claims, a description, and active service exports for the authenticated user's consumer namespace.

Backend Changes:

• POST /api/apply-binding — Accepts a consumer kubeconfig, deploys the konnector + creates an APIServiceBindingBundle on the consumer cluster automatically.
• GET /api/consumer-status — Returns whether the user has an existing consumer namespace and lists active exports.
• GET /api/konnector-manifests — Returns konnector deployment YAML (intentionally unauthenticated for easy download).
• Host alias resolution — Resolves the provider hostname from the backend pod and injects HostAliases into the
  konnector deployment, fixing connectivity in environments like Kind, where DNS names resolve to the loopback address.
• CRD bootstrap wait — ApplyToConsumer polls until the APIServiceBindingBundle CRD is established before creating the bundle resource.

BindingResponse gains optional ProviderNamespace and BindingName fields so the UI can display binding context after creation.

What Type of PR Is This?

/kind feature

Related Issue(s)

Fixes #406

Release Notes

Added the ability to bind Kubernetes services from a provider to a consumer cluster entirely through the
web UI.

[xrstf]

Overall this is a solid implementation of the browser-based binding flow. The tabbed UI approach with multiple methods (One-Click, Already Connected, Bundle, Manual) gives users good flexibility. A few items to address before merging:

Security

/api/konnector-manifests is unauthenticated - This endpoint is registered without RequireAuth. Is this intentional? If so, consider rate limiting since it reveals deployment details.

ClusterRole grants full cluster-admin - The konnector ClusterRole uses apiGroups: [""], resources: [""], verbs: ["*"]. Worth documenting why this broad access is required, or scoping it down if possible.

Consumer kubeconfig handling - The security note in the UI is good. Please confirm the kubeconfig bytes aren't logged anywhere (e.g., in error messages or debug logs).

Bug

Missing cluster parameter in handleConsumerStatus - At handler.go:189, the call to GetConsumerStatus passes identity and params.ClusterID, but looking at the implementation, it seems like the namespace lookup should work. However, double-check that the cluster context is being used correctly throughout the flow.

Suggestions

• Duplicate konnector definitions - The YAML template in handleKonnectorManifests and the Go structs in ensureKonnector define the same resources. Consider generating one from the other to avoid drift.
• Empty bindingName in non-UI flows - exportRequestName is only set for UI flows, so the response will include an empty BindingName for CLI flows. May want to omit the field entirely with omitempty behavior or always populate it.
• Compiled assets in PR - The web/dist/ changes could be generated in CI rather than committed, reducing diff noise.

---

Nice work on the polling logic with seenOnce to handle cache lag, and the idempotent create-or-update patterns throughout.

[cnvergence]

Keeping it as a draft again, need to clean the code a bit and put a write-up