feat(release-please): add TARGET_BRANCH input for maintenance branches

[rodrigo2604]

[MAC-2491]

What changes does this PR introduce

• Feature

Añade un input opcional TARGET_BRANCH a release-please-app.yml y lo propaga como target-branch del action, para poder correr release-please contra una rama de mantenimiento en lugar del default branch del repo.

      TARGET_BRANCH:
        description: 'Branch to open release PRs against and tag releases on ...'
        required: false
        default: ''
        type: string

        with:
          target-branch: ${{ inputs.TARGET_BRANCH }}
          include-component-in-tag: ${{ inputs.MONOREPO_TAGS_ENABLED }}
          token: ${{ steps.app-token.outputs.token }}

Any background context you want to provide

El problema

taxdown/build tiene master en 4.x y una línea de mantenimiento 2.x viva en release/v2 (hoy 2.3.1), con consumers clavados en ^2.3.0. Para que un backport mergeado en release/v2 genere release y publique en npm, release-please tiene que correr contra esa rama.

Añadir release/v2 al on.push del repo consumidor no basta: este reusable invoca el action sin target-branch, y con ese input vacío release-please cae al default branch del repo. Confirmado en src/index.ts — el input se propaga como defaultBranch del cliente GitHub, y de ahí a Manifest.fromManifest(github, github.repository.defaultBranch, ...); si viene undefined, se resuelve por API.

Resultado sin este PR: un push a release/v2 lanzaría el workflow, pero release-please leería el manifest de master (4.2.0) y gromearía el release PR contra master. Cero efecto sobre la línea 2.x.

Por qué es retrocompatible

~30 repos consumen este reusable con @main, así que el riesgo de regresión es lo relevante aquí. No lo hay: TARGET_BRANCH default '', y el action normaliza el string vacío a undefined:

function getOptionalInput(name: string): string | undefined {
  return core.getInput(name) || undefined;
}

Pasar target-branch: '' es por tanto indistinguible de no pasarlo. Todos los consumidores actuales mantienen exactamente el comportamiento de hoy; solo cambia el de quien opte explícitamente por el input.

Limitación conocida (no la toca este PR)

El job automerge busca el release PR con --head "release-please--branches--main" hardcodeado. release-please nombra esa rama release-please--branches--<target-branch>[--components--<component>], así que con TARGET_BRANCH puesto el find-pr no encontrará nada y el auto-merge hará no-op silencioso.

Vale la pena señalar que eso ya está roto hoy para cualquier repo cuyo default branch no sea main: en taxdown/build el head real es release-please--branches--master--components--build. Como AUTO_MERGE es opt-in y por defecto false, ningún consumidor actual lo sufre. Lo dejo fuera del scope a propósito; si queréis lo arreglo en un PR aparte derivando el head de TARGET_BRANCH y del default branch.

Where should the reviewer start

.github/workflows/release-please-app.yml — 6 líneas, el input nuevo y su propagación al step.

El primer consumidor será taxdown/build#130, que pasará TARGET_BRANCH: release/v2. Verificación end-to-end allí: que el release PR se abra contra release/v2 y que el tag salga v2.3.x.