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.

.gitea/workflows/APP_NAME-build.yaml

@@ -13,6 +13,8 @@ on:
     paths:
       - 'code/**'
       - 'helm/**'
+      - 'manifests/**'
+      - 'scripts/**'
       - '.gitea/workflows/__APP_NAME__-build.yaml'
   workflow_dispatch: {}
 
@@ -125,6 +127,36 @@ jobs:
           echo "$KUBECONFIG_B64" | base64 -d > "${HOME}/.kube/config"
           chmod 600 "${HOME}/.kube/config"
 
+      # ── ADR-066: AddonClaim vive FUERA del chart Helm ───────────────────
+      # El claim lo gestiona addon-provisioner via finalizer cleanup-logical;
+      # no debe acoplarse al lifecycle del release Helm para no rotar
+      # credenciales en cada upgrade.
+
+      - name: De-adoptar AddonClaim legacy (migracion chart 1.0.0 -> 1.1.0)
+        # Idempotente: skip silencioso si AddonClaim no existe (primera
+        # instalacion) o si ya esta de-adoptado (segundo run post-migracion).
+        # Si tiene annotations Helm de un release v1.0.0, las quita para que
+        # el siguiente helm upgrade no intente borrarlo (no esta en el chart).
+        # Sunset del step tras una rotacion completa (~2 semanas).
+        run: |
+          RELEASE_NAME=__APP_NAME__ bash scripts/pre-helm-detach.sh
+
+      - name: Aplicar AddonClaim
+        # Sustitucion de placeholders con sed (evita dependencia de envsubst,
+        # que no esta garantizado en la imagen del runner). kubectl apply es
+        # idempotente: primer push lo crea, push subsiguientes son no-op si
+        # el spec no cambia. helm upgrade --install nunca lo trackea ni lo borra.
+        env:
+          RELEASE_NAME: __APP_NAME__
+        run: |
+          # databaseName = release name con guiones a underscores + sufijo _db.
+          # Coincide con el default del chart 1.0.0 (.Release.Name | replace
+          # "-" "_" | printf "%s_db").
+          DATABASE_NAME="$(echo "${RELEASE_NAME}" | tr '-' '_')_db"
+          sed -e "s|\${RELEASE_NAME}|${RELEASE_NAME}|g" \
+              -e "s|\${DATABASE_NAME}|${DATABASE_NAME}|g" \
+              manifests/addonclaim.yaml | kubectl apply -f -
+
       - name: Helm upgrade --install
         env:
           TENANT_ID: ${{ vars.TENANT_ID }}
@@ -144,8 +176,8 @@ jobs:
             --wait --timeout 7m
             # 7m absorbe el peor caso del reconcile de addon-provisioner
             # (RECONCILE_INTERVAL 300s + initial_delay 60s) + StatefulSet MariaDB
-            # ready (~60s) + Job DDL (~10s) + InitContainer wait-for-secret (~5s)
-            # + Alembic upgrade. Ver helm/<APP_NAME>/templates/addonclaim.yaml.
+            # ready (~60s) + Job DDL (~10s) + InitContainer wait-for-secret + Alembic.
+            # AddonClaim ya fue aplicado en el step previo (ADR-066).
 
       - name: Verificar rollout
         run: |