chore: bump version to 1.3.3+162 [ci skip]

La app promete decibelios en cuatro sitios y no los entregaba en ninguno. El
slider abarca un +/-12 fijo, escribe el numero con su unidad debajo de cada
banda, y `equalizerBandValue` le dice literalmente "decibelios" a TalkBack. El
modelo documenta las bandas como dB y los presets de fabrica estan escritos en
dB. just_audio documenta `setGain` en decibelios y multiplica por 1000 para
llegar a milibelios sin normalizar nada: `minDecibels`/`maxDecibels` son la
CAPACIDAD del dispositivo, no una escala a la que normalizar.

Pese a eso, la ganancia se estiraba por `maxDecibels/12`. Un +6 dB llegaba como
+10 en un movil de rango ancho.

El estiramiento nunca fue una decision de diseño

Antes de a9202c6 el codigo era `setGain(preset.bandas[i])`, decibelios
literales. Ese commit metio la normalizacion sin docstring, sin test y sin nota
de diseño, y traia un fallo: 0 dB caia en el punto medio del rango, asi que un
preset PLANO realzaba. 3449e2c corrigio exactamente eso y nada mas -- su propio
mensaje dice que el objetivo era "0 dB es siempre 0" -- heredando el
estiramiento sin discutirlo. No hay ADR, spec ni comentario que lo justifique.

Lo que de verdad rompia: la portabilidad

Lo que se persiste y se exporta son los dB del usuario, sin escalar; el escalado
ocurre solo al escribir en el efecto nativo. Asi que el mismo backup suena
distinto en cada telefono, y la interfaz informa de una restauracion perfecta
mientras el audio no lo es. Peor con el rango asimetrico habitual de Android
([-12, +19]): los realces se multiplican por 1.58 y los cortes por 1.0, de modo
que el preset no solo sube de nivel, CAMBIA DE FORMA. Jazz [3, -1, -1.5, 2, 4]
se entregaba como [4.75, -1, -1.5, 3.17, 6.33]. Con presets por dispositivo, el
mismo preset se deformaba distinto en el altavoz y en el Bluetooth.

No es un clamp a secas

`db.clamp(minDecibels, maxDecibels)` habria reintroducido el fallo de 3449e2c:
en un dispositivo que reporte [+3, +19], el cero se convierte en +3 y el preset
plano vuelve a realzar. La ventana se fuerza a contener el cero, asi que se
conservan todas las invariantes ganadas -- 0 siempre es 0, el signo nunca se
invierte, el resultado nunca escapa del rango nativo, un dispositivo sin margen
en un lado no puede realzar por ese lado -- y solo desaparece el estiramiento.

Que se oye distinto: en un movil de +/-12 dB, identico a hoy. En uno de rango
ancho los realces bajan, hasta un 40% menos en dB en uno de +/-20. Los cortes
apenas se mueven, porque la forma habitual es [-12, +N] y el lado negativo ya
iba practicamente 1:1. A cambio, los seis presets de fabrica suenan por fin
igual en cualquier telefono.

Ningun preset guardado necesita migracion: lo almacenado siempre fueron los dB
del usuario.

Suite completa: 1534 pasan, 2 omitidos. flutter analyze mantiene los 5 avisos
preexistentes.

.gitea/workflows/build.yml

@@ -68,7 +68,18 @@ jobs:
           echo "keyPassword=$KEYSTORE_PASSWORD" >> android/key.properties
           echo "✅ Keystore configurado"
 
-      - name: Bump versión patch + commit
+      # PRO owns the version NAME; every branch advances the build NUMBER.
+      #
+      # Previously main also bumped its patch on every push, so main's semver
+      # raced permanently ahead of PRO's (main hit 1.3.3 while the branch that
+      # actually ships sat at 1.3.0). That buried the release artifacts under a
+      # dev branch on builds.freetimelab.es, which sorts by version, and made
+      # every main<->PRO merge conflict on pubspec.yaml.
+      #
+      # The build number still advances everywhere: Google Play requires it to
+      # be monotonic across the whole app, so two branches must never mint the
+      # same code.
+      - name: Bump versión + commit
         run: |
           BRANCH="${CURRENT_REF#refs/heads/}"
           git config user.name "ShanaiaBot"
@@ -77,12 +88,20 @@ jobs:
           SEMVER=$(echo "$CURRENT" | cut -d'+' -f1)
           BUILD=$(echo "$CURRENT" | cut -d'+' -f2)
           NEW_BUILD=$((BUILD + 1))
-          # If the triggering commit explicitly pins the version name via the
+
-          # [version set] marker, ship that semver as-is (a milestone like 1.0.0
+          # Look for [version set] across EVERY commit this push introduced,
-          # or a major/minor jump the automatic patch bump cannot reach) and only
+          # not just the tip. `git pull` inserts an auto-generated merge commit
-          # advance the build number, which Google Play requires to stay
+          # whose message carries no marker, which silently discarded a pinned
-          # monotonic. Otherwise keep the default automatic patch+build bump.
+          # version name and bumped 1.3.0 to 1.3.1 behind our backs.
-          if git log -1 --pretty=%B | grep -q '\[version set\]'; then
+          RANGO="${{ gitea.event.before }}..${{ gitea.sha }}"
+          if git log "$RANGO" --pretty=%B 2>/dev/null | grep -q '\[version set\]'; then
+            MARCADOR="si"
+          else
+            MARCADOR="no"
+          fi
+
+          if [ "$BRANCH" != "PRO" ] || [ "$MARCADOR" = "si" ]; then
+            # Non-release branches never touch the name; PRO respects a pin.
             NEW_VERSION="${SEMVER}+${NEW_BUILD}"
           else
             MAJOR=$(echo "$SEMVER" | cut -d. -f1)
@@ -91,6 +110,8 @@ jobs:
             NEW_PATCH=$((PATCH + 1))
             NEW_VERSION="${MAJOR}.${MINOR}.${NEW_PATCH}+${NEW_BUILD}"
           fi
+
+          echo "rama=${BRANCH} marcador=${MARCADOR} ${CURRENT} -> ${NEW_VERSION}"
           sed -i '' "s/^version: .*/version: ${NEW_VERSION}/" pubspec.yaml
           git add pubspec.yaml
           git commit -m "chore: bump version to ${NEW_VERSION} [ci skip]"
@@ -255,7 +276,29 @@ jobs:
           ETIQUETA="${BRANCH}-v${VERSION}+${BUILD_NUMBER}"
           APK_NOMBRE="pluriwave-${ETIQUETA}.apk"
           AAB_NOMBRE="pluriwave-${ETIQUETA}.aab"
-          DESTINO="/opt/ftl-builds/builds/pluriwave/v${VERSION}"
+          # La rama va en el NOMBRE DE LA APP, no en una subcarpeta.
+          #
+          # El objetivo sigue siendo el de siempre: que main y PRO no se mezclen
+          # en el portal, que ordena por número de versión y mostraba el build
+          # de desarrollo como "última versión" por delante del de release.
+          #
+          # Pero la primera solución metía la rama como TERCER nivel
+          # (pluriwave/main/v1.3.3/) y el portal indexa solo DOS —
+          # <app>/<versión>/<ficheros> —, así que desde el 29-08 ningún build de
+          # main volvió a aparecer en builds.freetimelab.es aunque el job saliera
+          # verde: el scp subía bien, a una ruta que el indexador no lee. Nada
+          # avisaba, y el echo de abajo se comía la rama y mandaba a la carpeta
+          # antigua, que llevaba congelada desde el +157.
+          #
+          # Con la rama en el nombre, PRO conserva la entrada limpia "pluriwave"
+          # y main tiene la suya, igual que ya conviven radar-foral y
+          # radar-foral-android.
+          if [ "$BRANCH" = "PRO" ]; then
+            APP="pluriwave"
+          else
+            APP="pluriwave-$(echo "$BRANCH" | tr '/' '-')"
+          fi
+          DESTINO="/opt/ftl-builds/builds/${APP}/v${VERSION}"
           SSH_KEY="/Users/freetlab/.openclaw/workspace/.secure/zimaboard_ed25519"
 
           ssh -i "$SSH_KEY" -o StrictHostKeyChecking=no ShanaiaBot@192.168.0.33 "mkdir -p ${DESTINO}"
@@ -265,8 +308,11 @@ jobs:
           scp -i "$SSH_KEY" -o StrictHostKeyChecking=no \
             build/app/outputs/bundle/release/app-release.aab \
             "ShanaiaBot@192.168.0.33:${DESTINO}/${AAB_NOMBRE}"
-          echo "✅ APK: builds.freetimelab.es → pluriwave → v${VERSION} → ${APK_NOMBRE}"
+          # La ruta se imprime desde ${APP}, no a mano: la version anterior tenia
-          echo "✅ AAB: builds.freetimelab.es → pluriwave → v${VERSION} → ${AAB_NOMBRE}"
+          # "pluriwave" escrito a fuego y mandaba a la carpeta equivocada cada
+          # vez que se compilaba algo que no fuera PRO.
+          echo "✅ APK: builds.freetimelab.es → ${APP} → v${VERSION} → ${APK_NOMBRE}"
+          echo "✅ AAB: builds.freetimelab.es → ${APP} → v${VERSION} → ${AAB_NOMBRE}"
 
       # La publicacion automatica en Google Play es OPCIONAL.
       #
@@ -319,9 +365,7 @@ jobs:
           if [ -z "$BOT_TOKEN" ]; then exit 0; fi
           if [ "${{ job.status }}" = "success" ]; then
             MSG="✅ *PluriWave* v${VERSION} · rama ${BRANCH} · ${COMMIT}%0AAPK + AAB generados"
-            # Solo se anuncia la subida a Play cuando de verdad ocurrio: el paso
+            # Solo se anuncia la subida a Play cuando de verdad ocurrio.
-            # se omite si falta el secreto, y un aviso que dice "publicado"
-            # cuando no se publico es peor que no avisar.
             if [ "$BRANCH" = "PRO" ] && [ "${{ steps.credenciales_play.outputs.disponible }}" = "si" ]; then
               MSG="${MSG}%0APublicado en Google Play · Internal Testing"
             elif [ "$BRANCH" = "PRO" ]; then

pubspec.yaml

@@ -1,7 +1,7 @@
 name: pluriwave
 description: "Radio mundial con ecualizador, reconocimiento de canciones y UI premium"
 publish_to: 'none'
-version: 1.3.4+162
+version: 1.3.3+162
 
 environment:
   sdk: ^3.7.0