[VC-45349] Rename cyberark-disco-agent to disco-agent across repo

…apshot

The purpose of the change is to give Discovery and Context service operators a
clear way to communicate uploaded secret findings and remediations with a team
or contact for the origin cluster, by allowing the platform-team to supply these
new configuration values when they deploy the agent:

-   `config.clusterName` — a human‑readable cluster name, and
-   `config.clusterDescription` — a short description (contact info, purpose).

These new fields are optional. If the clusterName is empty, the `ARK_USERNAME`
is used as the cluster-name. The rationale is that each agent deployment will be
assigned a unique "service account" which should be given a username derived
from the name of the target cluster. Therefore the service account username will
be sufficient information for the security team to communicate risks and
remediations to the platform team responsible for the cluster.

This provides an imperfect, but expedient improvement for Web UI users and
support for on‑prem / non‑cloud deployments which can be improved in future if
with more backend/ cloud discovery work.

It wasn't strictly necessary, but I also tried to sort out the confusion around
the `cluster_id` and the `cluster_name`. I've added a new `cluster_name` field
to the config file and updated the `venafi-kubernetes-agent` chart to set that
config field instead of the overloading the `cluster_id` field which is used for
other purposes by the much older Jetstack Secure agent.

Summary of changes:
- Add ClusterName and ClusterDescription fields to Snapshot struct
- Populate these fields from Options in PostDataReadingsWithOptions
- Add clusterName and clusterDescription Helm values and docs
- Populate cluster_id and cluster_description in the rendered configmap
- Update values.schema.json to include descriptions for the new values
- Add ClusterDescription field to pkg/agent Config and CombinedConfig
- Default MachineHub cluster name from ARK_USERNAME env when not set

Signed-off-by: Richard Wall <richard.wall@cyberark.com>