Should all local charm promote workflows allow a track input?

In order to promote the charm on track 2 from edge to beta, beta to candidate, and candidate to stable, we can't rely on the current local promote workflows which eventually call the central one stored in this repo. This is because the local manually dispatched WF's don't accept a track input. So the central promote job is triggered with the default track of stable, which means we can't promote track 2 for example. To make the manually dispatched WF work for BE K8s, I added the `track` input. Should other charms implement a similar option?

The PR that implemented this change for BE K8s (with some more context) is: https://github.com/canonical/blackbox-exporter-k8s-operator/pull/81
An example of a successful run is: https://github.com/canonical/blackbox-exporter-k8s-operator/actions/runs/22196059295

Review the central promotion workflow in this repository and compare it with the local manually dispatched workflow changed in blackbox-exporter-k8s-operator PR #81. Identify which charm workflows need a track input; done means those workflows accept and pass the selected track so promotions are not forced to stable.

Written by the indexing model from the issue text.