fix(kubernetes): derive Helm names accepted by Kubernetes

flowchart LR
  IN["deployment unit ref"] --> L["lowercase, runs outside a-z 0-9 - become -,<br/>trim -"] --> Q{"starts with<br/>a letter?"}
  Q -- "no" --> P["prepend r-"] --> C
  Q -- "yes" --> C["cut to 53 chars (Helm limit)"] --> OUT["release name<br/>= external ID for status / update / terminate"]

ref	release name
3f9c1e2a-... (UUID)	r-3f9c1e2a-...
podinfo_demo	podinfo-demo
podinfo	podinfo (unchanged)

flowchart LR
  F["fix/helm-release-name<br/>tf-sdk !201 (this MR)"] --> R["refactor/tfsdk-architecture-alignment<br/>(no parent MR yet)"]
  R -. "release step" .-> PUB["publish openop-tfsdk"] -. "bump pin, now 1.1.1" .-> SRM["SRM lockfile"]

The adapter used the deployment-unit reference directly as its Helm release name. UUIDs can start with digits and CAMARA instance names can contain underscores; charts naming Services after the release then failed Kubernetes validation.

Normalize the name to lowercase letters, digits and hyphens, prepend r- when needed, and retain Helm's 53-character limit. Valid existing names keep their spelling. Activation returns the derived external ID, which status/update/terminate continue to use. Also classify Helm invalid-object errors so the logs identify the actual failure.

Pipeline 28593 is red at its first step, isort, on 10 files this MR doesn't touch. The base branch fails on the same 10 files, so the job stopped before black, flake8 and pytest. Replaying the job in its image (python:3.12-slim) on both branches:

validate-mr step	base refactor/tfsdk-architecture-alignment	this MR
isort	10 files	the same 10 files, none from this diff
black	clean	clean
flake8	clean	clean
pytest common/edgecloud, common/network	3 + 3 passed	3 + 3 passed
pytest contract/	51 passed	60 passed (9 new)

Fixing those imports belongs on the base branch, not in this hotfix. The VM overlay exercised digit-leading UUIDs and a requested name containing an underscore through ready and deletion.

Target refactor/tfsdk-architecture-alignment: this is one hotfix commit on the new openop_tfsdk package, not the separate legacy adapter MR !199 (closed). No parent MR for the architecture-alignment branch was open when checked; agree its integration path with the SDK maintainers.

Release requirement: publish a new immutable openop-tfsdk version, then update SRM's pinned dependency and lockfile. SRM still pins 1.1.1; merging this source change alone does not ship it in SRM. The branch has no push pipeline; its CI validation job is configured for merge requests.