chart 0.3.0: AddonClaim FUERA del chart Helm (ADR-066 del IDP)

Bug en chart 0.2.x: AddonClaim era Helm hook pre-install,pre-upgrade
weight -10 SIN hook-delete-policy. El default Helm 3 es
before-hook-creation → borra el claim en cada upgrade → finalizer
cleanup-logical rotaba credenciales + atoraba release en pending-upgrade.

Cambios:
- helm/APP_NAME/templates/addonclaim.yaml eliminado.
- manifests/addonclaim.yaml creado con placeholders sed.
- scripts/pre-helm-detach.sh idempotente para migracion v1.0.0 → 1.1.0.
- .gitea/workflows/APP_NAME-build.yaml: 2 nuevos steps detach + apply
  AddonClaim entre kubeconfig y helm upgrade.
- Chart.yaml bump 0.2.0 → 0.3.0.
- README reescrito (3 pasos workflow + tabla hooks sin AddonClaim +
  seccion Por que FUERA del chart + opt-out actualizado).
- Comentarios stale del AddonClaim como hook -10 limpiados en
  networkpolicy.yaml, role-db-secret-reader.yaml, job-alembic-upgrade.yaml.

ADR-066 del IDP documenta la decision arquitectural completa.

scripts/pre-helm-detach.sh

@@ -0,0 +1,65 @@
+#!/usr/bin/env bash
+# Script de migracion v1.0.0 -> v1.1.0 del chart web-backend-python (ADR-066).
+#
+# Las apps desplegadas con chart 1.0.0 tienen el AddonClaim creado como Helm
+# hook con annotations `meta.helm.sh/release-name`, `app.kubernetes.io/managed-by=Helm`
+# y `helm.sh/hook`. El chart 1.1.0 mueve el AddonClaim FUERA del chart; el
+# workflow del tenant lo aplica con `kubectl apply -f` despues de este script.
+#
+# Sin de-adopcion, el siguiente `helm upgrade --install` veria el AddonClaim
+# en el state previo (release v_n) pero no en el manifest nuevo (chart 1.1.0)
+# → helm intentaria delete del recurso → el finalizer dropearia user/Secret.
+#
+# Este script:
+#   - skip silencioso si el AddonClaim no existe (primera instalacion).
+#   - skip silencioso si el AddonClaim NO tiene annotations Helm (ya de-adoptado).
+#   - de-adopta si encuentra annotations Helm — quita las labels/annotations
+#     que hacen que Helm lo reconozca como recurso del release.
+#
+# Idempotente. Sunset del script tras una rotacion completa de releases
+# desplegadas con chart 1.0.0 (~2 semanas).
+#
+# Variables de entorno requeridas:
+#   - RELEASE_NAME: nombre del release Helm (== nombre de la app del tenant)
+#   - KUBECONFIG:   apuntando al cluster tenant
+#
+# Uso (desde el workflow del tenant):
+#   RELEASE_NAME=__APP_NAME__ bash scripts/pre-helm-detach.sh
+
+set -euo pipefail
+
+: "${RELEASE_NAME:?ERROR: RELEASE_NAME no esta seteado}"
+NAMESPACE="${NAMESPACE:-apps}"
+CLAIM_NAME="${RELEASE_NAME}-db"
+
+# Comprobar existencia. kubectl get devuelve exit 1 si NotFound — capturamos
+# con `|| true` para no romper bajo `set -e`.
+if ! kubectl get addonclaim "${CLAIM_NAME}" -n "${NAMESPACE}" >/dev/null 2>&1; then
+  echo "[pre-helm-detach] AddonClaim ${CLAIM_NAME} no existe en ns ${NAMESPACE} — skip (primera instalacion)."
+  exit 0
+fi
+
+# Detectar si tiene annotations Helm — si no, ya esta de-adoptado.
+RELEASE_ANNOTATION=$(kubectl get addonclaim "${CLAIM_NAME}" -n "${NAMESPACE}" \
+  -o jsonpath='{.metadata.annotations.meta\.helm\.sh/release-name}' 2>/dev/null || echo "")
+
+if [ -z "${RELEASE_ANNOTATION}" ]; then
+  echo "[pre-helm-detach] AddonClaim ${CLAIM_NAME} sin annotations Helm — skip (ya de-adoptado)."
+  exit 0
+fi
+
+echo "[pre-helm-detach] AddonClaim ${CLAIM_NAME} con release=${RELEASE_ANNOTATION} — de-adoptando…"
+
+# Quitar annotations Helm — `-` sufijo significa "remove".
+kubectl annotate addonclaim "${CLAIM_NAME}" -n "${NAMESPACE}" \
+  meta.helm.sh/release-name- \
+  meta.helm.sh/release-namespace- \
+  --overwrite
+
+# Quitar label de managed-by — el hook tambien deja la annotation `helm.sh/hook`
+# en algunos casos; la dejamos viva porque no afecta el ownership tracking.
+kubectl label addonclaim "${CLAIM_NAME}" -n "${NAMESPACE}" \
+  app.kubernetes.io/managed-by- \
+  --overwrite
+
+echo "[pre-helm-detach] De-adopcion completa. El siguiente helm upgrade --install no tocara este AddonClaim."