Rename bot-posted check-run/status names and PR-comment branding, with a dual-emit grace period

[JSONbored]

Problem: Every reviewed pull request receives GitHub check-runs and PR comments posted under literal, hardcoded brand strings (currently Gittensory Context and Gittensory Orb Review Agent), plus PR-comment headlines, placeholders, and footer text carrying the same brand name. A third string, Gittensory Gate, is already retired from active use — it survives only as GITTENSORY_LEGACY_GATE_CHECK_NAME, referenced by the existing supersedeLegacyNames mechanism to finalize any already-pending run left over from a prior rename, and is never posted on a new check-run. All of it funnels through one choke point, createOrUpdateNamedCheckRun in src/github/app.ts, and the check-run names are the single highest-risk item in this entire rebrand outside the database migration: our own README (line 43) tells every self-host operator to make Gittensory Orb Review Agent a required branch-protection status check. We don't control, and can't inventory, how many external self-hosters did exactly that. Renaming the string outright means any of their required checks silently stop being satisfied and their PRs stop being mergeable, with no error message pointing at the cause.

Area: Backend / Integrations

Proposal:

Open question (needs a maintainer decision before starting): Do we dual-emit both the old and new check-run names for an announced transition window (extra API calls per review, but zero external breakage for anyone who hasn't updated their branch-protection settings), or do we do a hard cutover on an advance-announced deprecation date (simpler to implement and to reason about, but it will silently block merges for any self-hoster who hasn't updated their required-check name by that date)? This finding recommends dual-emit given the severity, but it is genuinely the maintainer's call and is called out here rather than decided unilaterally.

Once that's settled: introduce new check-run name constants alongside the existing ones in src/review/check-names.ts, and update createOrUpdateNamedCheckRun and its six callers (createOrUpdateCheckRun, createOrUpdateGateCheckRun, createOrUpdatePendingGateCheckRun, createOrUpdateSkippedGateCheckRun, createOrUpdateErroredGateCheckRun, createOrUpdateOverriddenGateCheckRun) to post under the new names — and, if dual-emit is chosen, under the old names too for the announced window. The existing finalizeLegacyPendingCheckRuns mechanism and its supersedeLegacyNames option only force-complete an already-pending legacy-named run to neutral on the same commit SHA; it does not create a new run under the legacy name for later commits, so it cannot substitute for whichever option is chosen above — it solves the hung-spinner problem, not the required-check problem.

Separately, and lower-risk because nothing in GitHub natively hard-blocks on comment text: update the PR-comment brand strings in src/review/unified-comment.ts (the '### ... {brand} result' headline and the renderReviewingPlaceholder '{brand} is reviewing…' text), the default brand values in src/review/unified-comment-bridge.ts (currently never overridden by any real call site), the footer text in src/github/footer.ts ('Checked by Gittensory…', which per that file's own comment is always appended even when a maintainer supplies custom footer text), and the 'Re-run Gittensory review' checkbox labels in src/queue/processors.ts and src/signals/engine.ts.

Deliverables:

• New check-run name constants defined and wired through createOrUpdateNamedCheckRun and all six callers.
• Whichever transition mechanism is chosen above, implemented and (if dual-emit) an announced end date for it.
• Updated brand strings in the PR-comment headline, reviewing placeholder, comment-bridge defaults, footer text, and both checkbox labels.
• README updated so the required-branch-protection-check instructions match whatever check-run name is live.

Acceptance criteria:

• No self-hoster's existing required branch-protection check silently stops being satisfied without an advance announcement and a defined transition mechanism.
• All PR-comment brand strings (headline, placeholder, footer, checkbox labels) reflect the new name.
• README's required-check instructions match the live check-run name(s) at every point in the transition.

Test scenarios:

• Post a check-run for a commit under the new naming and confirm a branch-protection rule still required on the old name behaves as expected under the chosen transition mechanism (still satisfied if dual-emit; documented as broken-until-updated if hard cutover).
• Verify finalizeLegacyPendingCheckRuns still correctly neutralizes a pre-existing pending legacy-named run on the same commit SHA and does not interfere with the new transition mechanism.
• Render a PR comment end-to-end and confirm the headline, reviewing placeholder, and footer all show the new brand text with no leftover old-brand string.

Resources:

• src/review/check-names.ts
• src/github/app.ts (createOrUpdateNamedCheckRun, finalizeLegacyPendingCheckRuns, and the six named-check-run callers)
• src/review/unified-comment.ts
• src/review/unified-comment-bridge.ts
• src/github/footer.ts
• src/queue/processors.ts
• src/signals/engine.ts
• README.md (required branch-protection check instructions)

Boundaries:

• Leave every reference to the separate gittensor network's own domain/name untouched.
• Do not pick the dual-emit-vs-hard-cutover answer unilaterally — that decision gates the start of this work.
• Do not touch the D1 database migration or any other sub-issue's scope in this milestone.

---

Part of #4761.

[linear-code]

JSO-3787