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.

helm/APP_NAME/templates/job-alembic-upgrade.yaml

@@ -5,9 +5,11 @@
 #   visible para `kubectl logs job/...` y diagnostico.
 #
 # InitContainer `wait-for-secret`:
-#   - El AddonClaim (hook weight -10) ya fue aplicado, pero addon-provisioner es
-#     timer-based (RECONCILE_INTERVAL 300s, initial_delay 60s) y materializa el
-#     Secret `{{ .Values.database.secretName }}` de forma asincrona.
+#   - El AddonClaim ya fue aplicado por el workflow del tenant ANTES del
+#     `helm upgrade --install` (ADR-066, vive FUERA del chart en
+#     manifests/addonclaim.yaml). addon-provisioner es timer-based
+#     (RECONCILE_INTERVAL 300s, initial_delay 60s) y materializa el Secret
+#     `{{ .Values.database.secretName }}` de forma asincrona.
 #   - El InitContainer hace busy-wait hasta que el Secret existe — absorbe la
 #     latencia del reconcile dentro del pod, sin tocar el operator ni
 #     bajar RECONCILE_INTERVAL global.