🔗 chore: Dispatch GitNexus Deploy When Index Is Bot-Triggered (#12621)

* fix: dispatch deploy from index when triggered by github-actions[bot]

GitHub Actions suppresses workflow_run events for workflow runs whose
triggering actor is GITHUB_TOKEN (to prevent recursive chains). This
means when gitnexus-pr-command.yml uses `gh api workflow_dispatch`
to kick off gitnexus-index.yml, the downstream gitnexus-deploy-do.yml
workflow_run trigger never fires — the PR command indexes the PR but
the new artifact never makes it onto the droplet.

Add a final step in gitnexus-index.yml that dispatches the deploy
workflow directly via API, but ONLY when the triggering actor is
github-actions[bot]. User-triggered runs (push, pull_request, manual
workflow_dispatch from the UI) continue to rely on workflow_run as
before, so we don't double-deploy.

Requires a new actions:write permission at the workflow level for
this dispatch. contents:read is unchanged.

* fix: resolve main/dev indexes by artifact name, not branch run query

The resolve step was querying listWorkflowRuns filtered by branch=main
and branch=dev, then assuming the latest successful run on each branch
produced the expected gitnexus-index-main / gitnexus-index-dev
artifact. That assumption breaks for /gitnexus index command runs:

The PR command workflow dispatches gitnexus-index.yml with ref=main
(because that's where the workflow file lives) and an input pr_number.
The resulting run has head_branch='main' but uploads its artifact as
gitnexus-index-pr-<N>, not gitnexus-index-main. listWorkflowRuns
returns that run as the "latest success on main", the download step
tries to fetch gitnexus-index-main from it, and the API returns
"no artifact matches any of the names or patterns provided".

Fix: resolve all indexes (main, dev, and PRs) through the same
listArtifactsForRepo path the PR discovery already uses. Looks up
the freshest non-expired artifact by name directly, so the run's
head_branch and event type don't matter — if the artifact exists,
we find it; if not, we warn and move on.

Side benefit: the resolution logic is now shorter and consistent
across branches and PRs.

* fix: paginate open PRs and parallelize artifact lookups

The resolve step was capped at 100 open PRs by github.rest.pulls.list's
per_page ceiling — LibreChat has 200+ open at any given time, so the
tail of the PR queue was silently skipped. On top of that, the inner
artifact lookup loop was serial, so even after pagination the resolve
step would take 40-60 seconds on a busy repo (one API call per PR).

- Replace the single-page rest.pulls.list call with github.paginate,
  which follows the Link header across pages and returns the full
  open-PR set regardless of count.
- Drop the 100-PR truncation warning that was a known-limitation
  notice for exactly this case.
- Batch the per-PR artifact lookups into groups of 10 via Promise.all.
  200 PRs now take ~10 seconds instead of ~60, and the burst stays
  well within the authenticated rate limit (5000/hr).
- Add a final core.info summary showing how many of the open PRs
  actually had a servable index artifact, so the log is useful for
  debugging why a specific PR isn't showing up on the droplet.

.github/workflows/gitnexus-index.yml

@@ -31,6 +31,7 @@ on:
 
 permissions:
   contents: read
+  actions: write # needed to dispatch gitnexus-deploy-do.yml on bot-triggered runs
 
 concurrency:
   # When triggered by the /gitnexus command, group by PR number so rapid
@@ -154,3 +155,23 @@ jobs:
           path: .gitnexus/
           include-hidden-files: true
           retention-days: 30
+
+      # GitHub suppresses workflow_run events for workflow runs whose
+      # triggering actor is GITHUB_TOKEN (to prevent recursive chaining).
+      # That means when this workflow is dispatched by gitnexus-pr-command
+      # via `gh api workflow_dispatch`, the deploy workflow's workflow_run
+      # trigger never fires. Manually dispatch the deploy here in that
+      # specific case — user-triggered runs continue to rely on the
+      # existing workflow_run trigger, so we don't double-deploy.
+      - name: Trigger deploy workflow for bot-triggered runs
+        if: github.triggering_actor == 'github-actions[bot]'
+        uses: actions/github-script@v7
+        with:
+          script: |
+            core.info('Triggering actor is github-actions[bot]; workflow_run would not fire. Dispatching gitnexus-deploy-do.yml manually.');
+            await github.rest.actions.createWorkflowDispatch({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              workflow_id: 'gitnexus-deploy-do.yml',
+              ref: 'main',
+            });