[vgpastor]

Objetivo: que fusionar en main publique sin pasos manuales.

iOS: el release automático se envía a revisión

• ensure-tags.yml pasa submit_for_review: true a build-ios.yml.
• El envío sale del job de macOS a un job Linux nuevo (Submit to App Review), así la espera a que Apple procese el build no consume minutos de macOS.
• El paso Python anterior no funcionaba: usaba altool --list-builds, que no existe, y appStoreVersionSubmissions, que es la API obsoleta. Lo sustituye .github/scripts/app-store-submit.mjs, adaptado del de sacadiez-app y que ya usa RocStatus#436. Con la API reviewSubmissions:
  1. espera a que el build esté VALID;
  2. crea o reutiliza la versión editable;
  3. adjunta el build;
  4. rellena "What's New" en cada idioma desde store-assets/whatsnew/<locale>.txt, que Apple exige en las actualizaciones;
  5. envía.
• Es idempotente: si la versión ya está en revisión o publicada, no hace nada. Si Apple bloquea el envío, el job falla en rojo y muestra también meta.associatedErrors (pendiente que se anotó en RocStatus).
• Verificado en seco contra App Store Connect con 0.1.19 (build 119). Autenticación, app y build VALID funcionan, y la versión, ya READY_FOR_DISTRIBUTION, se deja como está. El envío real se comprueba con la primera release posterior a esta PR.
• Al publicar cada versión: actualizar store-assets/whatsnew/es-ES.txt y en-US.txt. Si no se tocan, se reutiliza el texto genérico.

Plugin backend/emerkit-analytics: CD a srv07

• Está en producción: WordPress de GlobalEmergency en srv07 (/var/www/vhosts/globalemergency.online/httpdocs/wp-content/plugins/emerkit-analytics), servido en emerkit.globalemergency.online. Versión 1.0.1, activa. El código desplegado coincide con main salvo los finales de línea CRLF de la copia manual.
• Nuevo deploy-analytics.yml, con el mismo patrón que SITREP (push a main con filtro de rutas, concurrency, secretos SRV07_HOST/USER/DEPLOY_KEY) y rsync como el backend PHP de apuntate:
  • rsync --delete --delay-updates sin tests/ ni .md;
  • permisos 644/755 (la copia manual tenía los .php en 666, escribibles por cualquiera);
  • wp plugin is-active;
  • smoke test: /events responde 400 con un lote vacío y la redirección Android responde 302 a un HEAD, que no cuenta como clic.
• La clave de host de srv07 está fijada en el workflow; no se confía en la primera conexión.
• Cambio hecho en srv07: clave ed25519 nueva gha-emerkit-analytics-deploy con restrict, añadida a authorized_keys del usuario globalemergency.online (backup en authorized_keys.bak-20261103). La privada está en el vault (Hosting → srv07 deploy key EmerKit Analytics) y en los secretos del repo.

CI con PHP

ci.yml no cubría PHP. Nuevo job Analytics plugin (PHP):

• lint en PHP 7.4 (el mínimo declarado);
• lint en PHP 8.4 (el de producción);
• las cuatro pruebas existentes: contrato, adaptador WP, host dedicado y persistencia. La de persistencia usa un servicio MariaDB desechable del runner.

web/, linux/, macos/, windows/

No se publican en ningún sitio:

• ningún workflow los compila;
• las releases solo adjuntan APK y kit;
• GitHub Pages está desactivado;
• la web pública del proyecto (globalemergency.online/proyectos/emerkit) es otra web en Vercel (GlobalEmergency/Website), no flutter build web.

Son carpetas del scaffold de Flutter para desarrollo local, así que no necesitan CD. Si alguno empieza a publicarse, habrá que añadirlo.

Sin cambios de código de app: no hace falta subir versión.