Publish Helm charts as OCI artifacts

Nobody has claimed this yet.

### What problem are you trying to solve?

Linkerd's Helm charts (`linkerd-crds`, `linkerd-control-plane`, and the extension charts) are only distributed through the classic index-based HTTP Helm repository at `https://helm.linkerd.io/{stable,edge}`. They are not published as OCI artifacts to any registry.

This is increasingly out of step with how charts are consumed today:

- **Helm has supported OCI registries natively and enabled-by-default since v3.8.** OCI is now the recommended distribution mechanism, and `helm push`/`helm pull`/`helm install oci://...` are first-class.
- GitOps tooling (Argo CD, Flux) and internal chart mirrors increasingly standardize on `oci://` sources, so consumers currently have to self-mirror the Linkerd charts into their own OCI registry to fit that model.
- OCI distribution comes with content-addressable digests and cosign/Sigstore signing support, which strengthens supply-chain guarantees over an unsigned `index.yaml` repo.

Several other CNCF projects have already added OCI publishing for exactly these reasons (e.g. kubernetes-sigs/external-dns#4630, kubernetes/autoscaler#7086).

### How should the problem be solved?

Publish the Linkerd charts as OCI artifacts to a registry (e.g. `cr.l5d.io` alongside the existing images, or `ghcr.io/linkerd`) as part of the release pipeline, in addition to — not instead of — the existing HTTP repo so nothing breaks for current users.

Concretely:

- On each stable/edge release, `helm push` `linkerd-crds` and `linkerd-control-plane` (and the extension charts) to the chosen OCI registry.
- Optionally sign the pushed artifacts with cosign.
- Document the `oci://` install path in the "Installing Linkerd with Helm" docs.

Drawbacks / considerations:
- Adds a publishing step and a registry namespace to maintain.
- Two distribution channels to keep in sync (mitigated by driving both from the same release job).

### Any alternatives you've considered?

- **Self-mirroring** (the current workaround): consumers `helm pull` from `helm.linkerd.io` and `helm push` to their own OCI registry in CI. This works but pushes ongoing maintenance onto every user and defeats the point of an official artifact.
- **Staying HTTP-only:** functional, but misses digest-pinning/signing and forces the mirror workaround for OCI-first GitOps setups.

### How would users interact with this feature?

Install directly from the OCI registry with no `helm repo add` step:

```bash
helm install linkerd-crds oci://cr.l5d.io/linkerd/linkerd-crds \
--version -n linkerd --create-namespace

helm install linkerd-control-plane oci://cr.l5d.io/linkerd/linkerd-control-plane \
--version -n linkerd \
--set-file identityTrustAnchorsPEM=ca.crt \
--set-file identity.issuer.tls.crtPEM=issuer.crt \
--set-file identity.issuer.tls.keyPEM=issuer.key
```

And reference it directly in Argo CD / Flux sources via `oci://`.

### Would you like to work on this feature?

maybe

Start by locating the release pipeline and the existing publication process for the linkerd-crds, linkerd-control-plane, and extension charts. Determine how stable and edge releases are produced, then define the registry and signing choices before adding OCI publication alongside the HTTP repository. Done means release jobs publish all required charts and the Helm installation documentation shows a working oci:// path.

Written by the indexing model from the issue text.