fix(janitor): dual-org support for the wyre-technology/WYRE-AI fleet split

[asachs01]

Problem

The -mcp/node- fleet moved from being entirely under wyre-technology to being split across wyre-technology (13 repos) and WYRE-AI (50 repos, conduit included) sometime around 2026-08-24 evening/night — confirmed via org repo listings and org IDs, not inferred. dependabot-janitor.sh's repo enumeration was a single-org API call (ORG, defaulting to wyre-technology, and the workflow explicitly pinned it there), so it silently kept scanning only the 13 repos still under wyre-technology — no error, just 50 of 63 repos never looked at.

This is almost certainly the real explanation for a persistent ~80-108-PR "chronic dependabot backlog" that multiple scan-mcp-repos cycles reported today as steady-state review-gating — it wasn't; the janitor simply never reached most of those repos.

Fix

• ORG → ORGS (space-separated org list, default "wyre-technology WYRE-AI"; ORG kept as a back-compat single-org override).
• REPOS entries are now "org/name" pairs, not bare names — every downstream gh ... -R call now targets the repo's actual org directly, rather than assuming one global org.
• EXCLUDE_REPOS still matches on the bare repo name (unchanged behavior), now via an awk filter that's org-agnostic.
• Workflow: removed the ORG: ${{ github.repository_owner }} env line, which was silently overriding the script's own ORGS default back down to a single org — without this the script fix would have done nothing in production.

Verified live (read-only, before writing any code): the new enumeration logic finds 105 repos in scope (85 WYRE-AI + 20 wyre-technology, using the script's actual -mcp$|^mcp|^node- pattern, which is broader than just the *-mcp fleet) vs. the ~20 the old single-org call would find.

Known gap, left visible rather than silently forced

Not fully live yet — one line still gates it. Checked live via gh api orgs/WYRE-AI/installations: the wyre-projects-bot App (the one APP_ID/APP_PRIVATE_KEY mint tokens for) is not installed on WYRE-AI — only digitalocean, blacksmith-sh, vanta-with-task-management, and two infisical apps are.

Adding WYRE-AI to the token-minting step's owner: before that install exists risks failing token minting outright rather than degrading gracefully to a partial-org token — untested behavior of actions/create-github-app-token, and not worth risking the currently-working wyre-technology half of the janitor to find out. So owner: is left single-org for now, with the exact one-line change (add WYRE-AI to a newline-separated owner: list) documented inline in the workflow for whoever does the App install.

In the interim, ORGS already includes WYRE-AI, so every WYRE-AI repo will show up in each run's Errors section (pr list failed, an auth failure) until the install lands. This is expected and isolated per-repo — no crash, no effect on wyre-technology repos' processing — and turns a previously-invisible gap (silently scanning 13/63 with no error) into a visible, diagnosable one in the workflow's own summary output.

Ripples worth noting (per boss)

1. A prior Gate-7 sweep's enumeration recipe is now stale for reruns. analyst's 2026-08-24 ~14:2xZ Gate-7 verification enumerated all 63 *-mcp repos under wyre-technology — correct at the time, and its conclusions still hold, but a straight rerun of that same wyre-technology-only recipe today would only find 13. Anyone rerunning that verification needs the dual-org enumeration too.
2. Every org-level enumeration in fleet tooling needs the same dual-org treatment — this janitor, scan-mcp-repos cron prompts, any stale-PR sweep, anything that does a full-org repo listing. Per-repo gh calls (PR view, run list, etc.) already survive the split via GitHub's transfer redirect; only enumeration is affected. Flagging so this isn't treated as a one-off fix specific to the janitor.

Verification

• bash -n on the script: syntax OK.
• python3 -c "import yaml; yaml.safe_load(...)" on the workflow: valid.
• Live-tested the new REPOS enumeration end-to-end against real org data (read-only gh api calls, no merges/mutations): 105 repos found, correctly split 85/20 across the two orgs, WYRE-AI/timezest-mcp present, EXCLUDE_REPOS filtering verified correct on a synthetic multi-org test case.
• Did not run the full janitor (merge/review logic) — that needs the App-token auth this PR doesn't yet have for WYRE-AI, and running it for real against wyre-technology wasn't necessary to verify this specific fix.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}

[asachs01]

Disclosure: this is my own PR from 2026-08-25 (forge) — flagging that rather than presenting a fresh review of unfamiliar work. Native approve is blocked by shared identity regardless, so this is a currency re-check instead of an independent review:

• Branch is still up to date with main (baseRefOid matches current main HEAD exactly, mergeStateStatus: CLEAN) — no drift in 2 days.
• Re-verified the documented gap is still accurate: gh api orgs/WYRE-AI/installations still shows wyre-projects-bot NOT installed (only digitalocean/blacksmith-sh/vanta/2x infisical) — the single-org owner: limitation this PR documents inline is still the correct interim state, not stale.
• No code changes needed. Still awaiting the App-install (separate [HUMAN]/ops item) before the WYRE-AI half goes fully live, and the usual Aaron override bundle for merge.