Rename brand literals embedded in public API/webhook data payloads

[JSONbored]

Problem: Several unauthenticated, publicly embeddable/consumable payloads bake the old brand name in as data rather than as code identifiers, so a code-only rename pass misses them. This spans the public README badge SVG/JSON, the /health and MCP-compatibility descriptors, and outbound Discord/Slack/PagerDuty notification payloads — the Discord username field and matching embed footer text in particular are directly customer-visible: they're the literal sender name and footer line a self-host operator sees on every notification in their own Discord channel.

Area: API / Notifications

Proposal: Rename each of these embedded brand literals from the old name to the new one, and along the way fix the one maintainability gap found in the same sweep: the badge.json 404 fallback in src/api/routes.ts duplicates the LABEL literal from src/api/badge.ts instead of importing it — consolidate to a single source so the two can't drift again.

Deliverables:

• src/api/badge.ts line 8's LABEL constant renamed, with the public README badge SVG/JSON output (via buildShieldsBadge/renderBadgeSvg/renderUnavailableBadgeSvg) reflecting the new brand.
• src/api/routes.ts line 937's /health payload service field renamed, and line 1004's badge.json 404 fallback importing badge.ts's label instead of duplicating the literal.
• src/services/mcp-compatibility.ts lines 28 and 47 renamed to match.
• src/services/notify-discord.ts's username: "Gittensory" call sites (lines 128, 179) and src/services/review-recap.ts's matching username: "Gittensory" call site (line 156) renamed to the new brand.
• The Discord embed footer text (`Gittensory · ...`) renamed alongside it in src/services/notify-discord.ts (lines 140, 193) and src/services/review-recap.ts (line 167) — it renders in the same customer-visible embed as the username.
• The actor: "gittensory" literal renamed consistently everywhere it appears across src/services/notify-discord.ts, src/services/review-recap.ts, and src/services/notify-pagerduty.ts, including the same value passed as the lookup argument to countRecentAuditEventsForActorAndTarget in notify-pagerduty.ts (line 178) — that lookup must stay in sync with the recorded actor value or the paging-cooldown query will silently stop matching newly recorded events.
• src/services/notify-pagerduty.ts's source: "gittensory" PagerDuty event payload field (line 194) renamed.

Acceptance criteria:

• The public badge SVG/JSON, /health payload, and MCP-compatibility descriptor all serve the new brand name with no old-name literals remaining.
• Discord notifications show the new brand as both the sender username and the embed footer text in a live self-host Discord channel.
• Every actor field (and the matching audit-lookup argument) across the three notification services is consistent (same new brand string, no stragglers).
• The badge.json 404 fallback imports its label from badge.ts rather than hardcoding a second copy.

Test scenarios:

• Fetch the public badge endpoint (both the SVG and the JSON variants, including the 404/unavailable fallback) and confirm the rendered label matches the new brand with no old-name leftover.
• Hit /health and the MCP-compatibility endpoint and confirm the service fields report the new brand.
• Trigger a real Discord notification and a PagerDuty event in a self-host environment and confirm the visible username, footer, and source fields show the new brand.
• Grep the six touched files afterward for the old brand string to confirm no literal was missed.

Resources:

• src/api/badge.ts (line 8)
• src/api/routes.ts (lines 937, 1004)
• src/services/mcp-compatibility.ts (lines 28, 47)
• src/services/notify-discord.ts (lines 106, 128, 140, 174, 179, 193, 199, 204, 224, 233, 238)
• src/services/review-recap.ts (lines 147, 156, 167, 181, 193, 214, 240, 252)
• src/services/notify-pagerduty.ts (lines 130, 178, 194)

Boundaries:

• Leave every reference to the separate gittensor network's own domain/name untouched — this issue is only about the old product brand literal, never the permanent SN74 gittensor name, and the two are easy to confuse by a careless find-and-replace in these same files.
• Do not touch the subnet-interface.ts PUBLIC_GITHUB_APP_SLUG/provider.name install-link literals — those are already covered by the install-link sweep in GitHub App rename #4772; this issue is scoped strictly to the badge, health/MCP descriptor, and notification-payload literals listed above.

---

Part of #4761.

[linear-code]

JSO-3796