revert(ci): open release-please PR with app token instead of GITHUB_TOKEN

[sebastiancorrea81]

Por qué

Revierte #195. Ese cambio buscaba evitar el gate de aprobación manual de GitHub Actions (action_required) en los workflows disparados por pull_request sobre el PR de release, pero:

• No era necesario: nullplatform/tofu-modules tiene el mismo release-please corriendo con el GITHUB_TOKEN default (identidad github-actions[bot]) y ya resolvió ese mismo problema de otra forma (ver fix(ci): trigger release PR auto-merge via workflow_run instead of pull_request #178) sin tocar la identidad que abre el PR.
• Introdujo una regresión real: la GitHub App (APP_RELEASE_ID) usada para el token nunca tuvo el permiso Pull requests: write (solo se le dio Contents: write, suficiente para el gh pr merge --admin de auto-merge-release.yml). El primer run tras mergear fix(ci): open release-please PR with app token instead of GITHUB_TOKEN #195 pudo crear la rama y el commit del release, pero falló al abrir el PR con Resource not accessible by integration, dejando una rama huérfana (release-please--branches--main) sin PR.

Fix real

El camino correcto es #178: cambiar el trigger de auto-merge-release-pr de pull_request a workflow_run, que no está sujeto al gate de aprobación de outside-collaborators (ya validado en producción en nullplatform/tofu-modules#479). Este PR solo deshace la parte de #195; #178 se mergea por separado.

Test plan

• Mergear este revert.
• Mergear fix(ci): trigger release PR auto-merge via workflow_run instead of pull_request #178.
• Confirmar que el próximo push a main hace que release-please (con GITHUB_TOKEN default) cree el release PR normalmente, y que auto-merge-release-pr (ahora vía workflow_run) lo mergee sin quedar en action_required.