Add a tool that generates the RBAC needed to install and to use Telepresence

Please describe your use case / problem.

RBAC is one of the sharpest edges in adopting Telepresence, and it bites in two distinct places:

1. Install-time (admin) RBAC. Whoever installs the traffic-manager needs permission to create everything in the chart — ClusterRole/ClusterRoleBinding, a MutatingWebhookConfiguration, plus the namespaced Deployment/Service/Secret/ServiceAccount/Role/RoleBinding set (and more when the node-agent is enabled). Someone without cluster-admin discovers this one denial at a time, and translating "cannot create mutatingwebhookconfigurations" into a reviewable manifest for their cluster admin is manual, error-prone work.

2. Use-time (client) RBAC. Non-admin users need the clientRbac roles the chart can render: port-forward and pod access in the manager namespace, plus per-namespace rules for the namespaces they work in (or a cluster-scoped variant with namespace discovery). Getting clientRbac.subjects, clientRbac.namespaces, and the scope right — and keeping them in sync with how the manager was actually installed — is guesswork today, and the docs can only describe the general shape, not the user's cluster.

Both cases end the same way: the person who needs access can't grant it, and the person who can grant it doesn't know exactly what to grant. The information needed to answer precisely (which chart objects this install actually creates, which of them the identity may already create, which namespaces are in scope) is knowable from the cluster, so a tool can do better than a doc page.

Describe the solution you'd like

A dedicated RBAC assistant — a telepresence rbac-style command — that generates ready-to-review manifests for both audiences:

• Admin/install mode: render the chart for the intended configuration, probe the current identity with SelfSubjectAccessReview against every object it would create, and emit a ClusterRole/ClusterRoleBinding plus per-namespace Role/RoleBinding covering exactly the denied verb/resource pairs — nothing broader. The output should name the requester as the subject, be deterministic (so it diffs cleanly in GitOps), and carry a header explaining what produced it and what the admin should check before applying.
• Client mode: given the subjects and the namespaces they need, emit the client-side roles matching how the traffic-manager is actually installed (cluster-wide vs. namespaces vs. namespaceSelector), including the manager-namespace connect role and the logs role when the manager's own namespace isn't otherwise granted. Equivalently, emit the clientRbac.* values block for people who manage the install through Helm.
• Verify mode: given an identity, report whether it can currently install, or connect and attach to workloads, and itemize precisely what is missing — the same probe used to generate, run as a check.

This complements, rather than duplicates, the chart's clientRbac templates: the chart renders roles for an install you control, while this tool answers "what do I need, and what am I missing" against a cluster you may not own.

Describe alternatives you've considered

• Documentation only (today's docs/reference/rbac.md): accurate but generic. It cannot tell a user which of the listed permissions they are actually missing, nor scope the result to their namespaces.
• Folding it into telepresence setup: an early draft of setup carried an RBAC-emitting flag. It was removed deliberately — setup is often a new user's first command, and RBAC generation is an advanced, admin-facing concern that deserves its own surface rather than another flag on an onboarding path. setup still reports which install privileges are missing, which is the natural hand-off point to this tool.
• kubectl auth can-i by hand: workable for one resource at a time, but the user must already know the full object list the chart produces, which changes with the configuration (node-agent, webhook, QUIC service, namespace scoping).

Versions (please complete the following information)

• Applies to current v2 (checked against the release/v2 chart and clientRbac templates); no existing command covers this.
• Kubernetes Environment and Version: cluster-agnostic; the probing relies only on SelfSubjectAccessReview and the rendered chart.

Additional context

Related existing pieces that a tool like this would build on: the clientRbac chart templates (charts/telepresence-oss/templates/clientRbac/), the RBAC reference documentation, and the privilege probing added for telepresence setup, which already renders the chart client-side and sweeps every object with SelfSubjectAccessReview.