fix(github): fallback to public Orb slug when GITHUB_APP_SLUG is unset

[JSONbored]

Motivation

• The stale-approval dismissal path computed the bot login from env.GITHUB_APP_SLUG unguarded, which becomes undefined[bot] when the env var is removed and prevents dismissal of real Orb approvals, weakening branch-protection integrity.
• The change restores the intended security behavior by falling back to the publicly-installable Orb slug while preserving self-host behavior when an operator provides their own GITHUB_APP_SLUG.

Description

• Add a PUBLIC_GITHUB_APP_SLUG = "gittensory-orb" constant and compute the effective bot login with env.GITHUB_APP_SLUG?.trim() || PUBLIC_GITHUB_APP_SLUG inside dismissLatestBotApproval so dismissal still targets the real Orb bot when the env var is absent.
• Update the dismissLatestBotApproval implementation to use the trimmed/ fallback slug before scanning reviews.
• Extend test/unit/github-pr-actions.test.ts by allowing env overrides in envWithKey(...) and adding regression tests that cover the unset and blank GITHUB_APP_SLUG branches which assert that gittensory-orb[bot] approvals are still dismissed.
• Preserve existing behavior when GITHUB_APP_SLUG is configured so self-host deployments continue to prefer their configured slug.

Testing

• Ran the targeted unit test file with npx vitest run test/unit/github-pr-actions.test.ts, and the file's tests passed (42 tests passed).
• Attempted a full coverage run with npm run test:coverage, which exercised the test harness but failed global coverage thresholds and encountered long-running unrelated test suites in this environment, so the full unsharded coverage job did not report a green result.
• Ran npm run typecheck, which failed due to pre-existing/unrelated typing issues in other packages and files and not due to the changes in this PR.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[gittensory-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-12 21:16:13 UTC}

2 files · 2 blockers · readiness 89/100 · CI green · unstable

⏸️ Suggested Action - Manual Review

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue — Link the relevant issue (for example `Closes #123`) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	No AI review summary
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (draft PR; no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 44 registered-repo PR(s), 36 merged, 435 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 44 PR(s), 435 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 44 PR(s), 435 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Mark ready when done.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.37%. Comparing base (c3ff768) to head (12a56f0).
⚠️ Report is 20 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5352   +/-   ##
=======================================
  Coverage   94.37%   94.37%           
=======================================
  Files         474      474           
  Lines       40128    40130    +2     
  Branches    14631    14632    +1     
=======================================
+ Hits        37869    37871    +2     
  Misses       1583     1583           
  Partials      676      676           

Flag	Coverage Δ
shard-1	46.28% <33.33%> (-0.28%)	⬇️
shard-2	34.74% <33.33%> (+0.06%)	⬆️
shard-3	32.06% <33.33%> (-0.04%)	⬇️
shard-4	31.97% <100.00%> (-0.11%)	⬇️
shard-5	33.45% <33.33%> (-0.15%)	⬇️
shard-6	45.07% <33.33%> (+0.23%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/github/pr-actions.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JSONbored]

Closing as a regression, not a fix.

${env.GITHUB_APP_SLUG}[bot] unset does become the literal string "undefined[bot]" — but that's already a safe no-op (no real GitHub bot is named undefined), not an active bypass. It's the same fail-closed outcome as the explicit pattern in isOwnGitHubAppCheckRun/isOwnReviewThreadAuthor (src/github/backfill.ts), just implemented implicitly via string coercion instead of an explicit early-return.

More importantly, this PR's fix inverts a deliberate design decision from #5269 (d56f4ec), which was already merged into main before this branch was created. That commit established two distinct patterns on purpose: own-bot-identity checks (this one's category, per isOwnReviewThreadAuthor's own comment listing pr-actions.ts as a sibling) degrade to "no match" when GITHUB_APP_SLUG is unset — never a hardcoded fallback — while PUBLIC_GITHUB_APP_SLUG = "gittensory-orb" is reserved for a completely different, public-facing "which app to install" descriptor (src/services/subnet-interface.ts). This PR imports that public constant into an own-identity comparison, which #5269 explicitly reasoned against ("decoupled from whatever credentials this Worker happens to hold for its own operational purposes").

It also only patches 1 of 5 byte-identical ${env.GITHUB_APP_SLUG}[bot] sites (comments.ts, project-tracker-adapter.ts, processors.ts, review-evasion.ts are untouched), so even taken at face value it wouldn't close the claimed gap.

If we want the explicit fail-closed idiom applied consistently, the right shape is extending backfill.ts's existing pattern (or factoring a shared resolveOwnBotLogin(env) helper) across all 5 call sites — not a hardcoded slug fallback. No action needed right now; flagging for whoever revisits this.