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/role-db-secret-reader.yaml

@@ -4,11 +4,13 @@
 # (hook pre-install/pre-upgrade weight 0) que hace busy-wait hasta que
 # addon-provisioner publica el Secret tras reconciliar el AddonClaim.
 #
-# Hook weight "-7" — entre AddonClaim (-10) y SA (-5):
+# Hook weight "-7" — entre NetworkPolicy (-8) y SA (-5):
 #   - Garantiza que RBAC exista antes de que el SA del hook -5 se materialice
 #     y antes de que el Job -0 intente leer el Secret.
 #   - delete-policy: before-hook-creation para que sea idempotente entre upgrades
 #     sin dejar Roles huerfanos.
+# (El AddonClaim ya no es hook del chart desde 0.3.0 — ADR-066. Lo aplica el
+# workflow del tenant ANTES del `helm upgrade --install`.)
 #
 # Scope minimo: solo lectura (get/watch) del Secret `<release>-db-creds`, no
 # secrets cluster-wide ni del ns `addons`. El root Secret de MariaDB vive en