chore(selfhost): investigate duplicate check-run surfaces in one-shot review mode

[JSONbored]

Context

Sub-issue of #1936 (beta-stable release readiness roadmap) — self-host optimization/cleanup item.

Problem

The self-hosted review stack posts two GitHub check-run surfaces on a PR:

1. Gittensory Orb Review Agent — required check, the actual review/gate result (merge/close/block decision).
2. Gittensory Context — a neutral/advisory check controlled by checkRunMode, posting "Gittensory context posted."

Live observation: setting check_run_mode=enabled (with dry-run disabled) causes Gittensory Context
to appear alongside the Orb Review Agent check. Audit metadata shows publishedOutputs containing both
gate_check_run and check_run. Gittensory Context isn't required by branch protection, but in a
one-shot review model (a PR should clearly merge/close/block through the single required Orb Review
Agent check) it reads as redundant CI noise that may confuse maintainers/contributors.

Relevant code paths

• Check names: src/review/check-names.ts (GITTENSORY_CONTEXT_CHECK_NAME, GITTENSORY_GATE_CHECK_NAME)
• Context check publisher: src/github/app.ts (createOrUpdateCheckRun())
• Context check output copy: src/rules/advisory.ts ("Gittensory context posted")
• Public surface publish path: src/queue/processors.ts (publishedOutputs.push("check_run") vs. "gate_check_run")
• Settings: checkRunMode (Context check) vs. gateCheckMode (Orb Review Agent gate check)

Questions to answer (analysis first, no code changes until understood)

1. What unique information does Gittensory Context provide that isn't already in the Orb Review
   Agent check output, the unified review comment, or the maintainer dashboard?
2. Is Gittensory Context legacy/advisory-era behavior that should default OFF for self-host
   one-shot review mode?
3. Should checkRunMode default to off everywhere, especially for self-host/orb one-shot mode?
4. Should enabling gateCheckMode automatically suppress Gittensory Context unless explicitly requested?
5. Should Gittensory Context be deprecated, folded into the Orb Review Agent output, or left as
   opt-in only?
6. Do any branch-protection rules, permissions, onboarding flows, dashboard views, or existing
   tests rely on Gittensory Context existing?
7. Do current docs/config examples accidentally encourage enabling both checks?

Expected direction (pending investigation)

For one-shot self-host review mode, prefer a single public check surface: keep
Gittensory Orb Review Agent, suppress Gittensory Context by default, and leave it available only
as an advanced opt-in if a real use case for it turns up. Any implementation must stay generic (no
hardcoded maintainer/repo identity), must not weaken gate finalization, and must not silently break
an existing install that explicitly enabled checkRunMode without a documented migration/defaulting
plan — plus updated docs/examples/private-config templates and tests covering both check-mode
combinations.

Findings from the investigation will be posted as a comment on this issue before any implementation PR.

[linear-code]

JSO-2516

[JSONbored]

Investigation findings (analysis only — no code changed)

Traced both check-run publish paths end-to-end. Summary first, then the corrected detail per
question from the issue body.

Confirmed: the two checks are fully independent, and the Context check is low/zero-signal by default

• src/signals/settings-preview.ts:100 — const willCheckRun = settings.checkRunMode === "enabled";
  is the only input to the Context-check decision. Nothing reads gateCheckMode here, and
  nothing in src/queue/processors.ts's gate-check publish path reads checkRunMode either — the
  two surfaces are decided, and published, on completely separate code paths with zero cross-gating.
• src/rules/advisory.ts:391-419 (formatCheckRunOutput) — at checkRunDetailLevel: minimal (the
  documented default), the Context check body is literally the string "No detailed findings are published in check runs." — every time, regardless of the actual review outcome. At standard/
  deep, it republishes each finding's already-public publicText, i.e. the same lines the
  advisory engine already contributes to the unified PR comment — not new information, a second
  rendering of the same information.
• No branch-protection, permission, onboarding, or dashboard logic depends on Gittensory Context
  existing. A publish failure for it is caught and logged (failedOutputs.push(...) in
  src/queue/processors.ts) without aborting the review or affecting the gate check.

Correction to a claim in my own research pass — verify defaults before trusting a single migration file

My first pass here concluded checkRunMode has a live default contradiction (DB schema default
'enabled' vs. code fallback 'off') by reading migrations/0002_repository_settings.sql:5
(check_run_mode TEXT NOT NULL DEFAULT 'enabled') in isolation. That's stale: a later migration,
migrations/0009_github_app_visibility.sql:11, does an unconditional
UPDATE repository_settings SET check_run_mode = 'off', ... across every existing row, and the
current Drizzle schema (src/db/schema.ts:51) declares
checkRunMode: text("check_run_mode").notNull().default("off") — matching the code fallback
(src/db/repositories.ts:469) and the documented default in .gittensory.yml.example:254
(Default: off). All three layers agree today: off is the real, current, self-consistent
default. There is no live drift to fix here, and no risky backfill/migration is needed for
existing installs.

That actually simplifies the situation described in this issue: the reported live incident
(checkRunMode=enabled on a self-host deploy) was an explicit opt-in away from the safe
default, not something operators fall into by default. The gap isn't the default — it's that
enabling it silently produces a second, redundant, mostly-empty check with no documentation
warning that it duplicates the required Orb Review Agent check and the PR comment.

Answers to the remaining questions

• Legacy/advisory-era? Yes — GITTENSORY_LEGACY_GATE_CHECK_NAME = "Gittensory Gate" in
  src/review/check-names.ts alongside the current GITTENSORY_GATE_CHECK_NAME = "Gittensory Orb Review Agent" confirms the gate check itself was renamed/evolved after the Context check already
  existed; the agent-pause suppression comment in src/queue/processors.ts ("suppress all public
  surface mutations (label, comment, context check run) ... The review-agent check run still
  posts") treats the two as architecturally distinct tiers — advisory vs. required — by design.
• Docs encourage enabling both? .gittensory.yml.example documents checkRunMode and gate:
  in separate sections with no cross-reference and no explanation that turning on checkRunMode
  adds a second, mostly-redundant check surface once gate.enabled: true is already set. That's a
  real documentation gap worth closing regardless of any code change.

Recommendation

No default needs to change. For one-shot self-host review mode, the fix is:

1. Document clearly (in .gittensory.yml.example and config/examples/README.md) that
   checkRunMode is an independent, legacy advisory surface that duplicates information already in
   the required Orb Review Agent check and the PR comment, and that one-shot installs should leave
   it at its default off.
2. Leave Gittensory Context as an opt-in-only surface (no forced suppression when gateCheckMode
   is on) — no evidence of a real use case that requires deprecation or removal, just clearer
   guidance so an operator doesn't enable it by accident expecting extra signal it doesn't provide
   at the default detail level.

No code changes are proposed from this investigation. If a docs-only PR is wanted for item 1 above,
I can open one; deeper changes (e.g. an explicit interaction between checkRunMode and
gateCheckMode) don't look justified given there's no live default-drift bug and no hard
dependency forcing Gittensory Context to exist.