fix: stop referencing secrets directly in a step if: condition

[Santisoutoo]

Descripción

PR #101 cambió el if: del paso "Install Cursor CLI" a:

if: steps.pick.outputs.empty == 'false' && secrets.CURSOR_API_KEY != ''

Al intentar re-lanzar el agent-loop sobre el issue #85 (para probar el fix de timeout de #102), gh workflow run devolvió:

HTTP 422: Invalid Argument - failed to parse workflow: (Line: 138, Col: 13):
Unrecognized named-value: 'secrets'. Located at position 40 within expression:
steps.pick.outputs.empty == 'false' && secrets.CURSOR_API_KEY != ''

GitHub rechaza referenciar secrets directamente en el if: de un step. Esto no es solo un problema de workflow_dispatch manual — rompe el fichero de workflow entero, así que también habría bloqueado el próximo cron (06/13/20 UTC).

En el resto del fichero, cada acceso a un secret pasa por env: (el patrón permitido); esta era la única línea que lo hacía directamente en un if:.

Cambio

• pick-issue.sh ya calcula CURSOR_AVAILABLE a partir del secret dentro de su propio env: (patrón seguro). Lo expone ahora como output cursor_available=true|false.
• agent-loop.yml gatea "Install Cursor CLI" con steps.pick.outputs.cursor_available == 'true' en vez de secrets.CURSOR_API_KEY != ''.

Mismo comportamiento pretendido (instalar el CLI de Cursor siempre que el secret esté configurado, no solo cuando el worker enruta a Cursor), sin tocar secrets desde un if:.

Checklist

• bash -n en ambos scripts modificados
• Verificado que es la única ocurrencia de secrets\. dentro de un if: en .github/workflows/*.yml
• Sin cambios de superficie de permisos/secretos

closes ninguno — bug de infra descubierto durante el testing manual de #102, no ligado a un issue de producto.