fix(ui): flag the incident strip's scope when it reports a different subnet (#3951)

[real-venus]

Summary

Closes #3951

The global incident strip surfaces the network's single top active incident on every /subnets and /endpoints route, but on a subnet detail page it gave no signal when that incident concerned a different subnet — so "Degraded … SN10"
rendering directly above SN1's masthead read as SN1's own status (#3951).

This derives the current subnet from the path and, when the incident's subject differs (another subnet, or a non-subnet network-wide notice), renders an explicit scope chip ("Other subnet" / "Network-wide") next to the severity label, so the banner can't be misread as the current page's health.

Changes

• components/metagraphed/incident-strip.tsx — compute concernsOtherEntity from the current /subnets/<n> path vs. the incident's netuid, and render a scope chip when they differ.

Screenshots

Incident strip on /subnets/1 while the active incident concerns SN10 (mocked
for a deterministic capture). The only change is the "Other subnet" scope
chip after the "Degraded" label — captured at fixed viewports via Playwright.

Viewport · Theme	Before	After
Desktop · Light	before	after
Desktop · Dark	before	after
Tablet · Light	before	after
Tablet · Dark	before	after
Mobile · Light	before	after
Mobile · Dark	before	after

Validation

• tsc --noEmit ✓ · prettier --check (3.9.4) ✓ · eslint (0 errors) ✓
• vitest run — 665/665 pass ✓ · build ✓
• No new API call (uses the existing incidents query) → no HAR re-record

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.94%. Comparing base (0cd39a9) to head (22ccc41).
⚠️ Report is 11 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4943   +/-   ##
=======================================
  Coverage   97.94%   97.94%           
=======================================
  Files         163      163           
  Lines       19460    19460           
  Branches     7373     7373           
=======================================
  Hits        19060    19060           
  Misses         53       53           
  Partials      347      347           

🚀 New features to boost your workflow:

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

[gittensory-orb]

Warning

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-13 00:33:37 UTC}

1 file · 1 AI reviewer · no blockers · readiness 100/100 · CI green · blocked

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review: This PR changes guardrail-protected path(s): apps/ui/src/components/metagraphed/incident-strip.tsx (matched apps/ui/**).

Review summary
Adds a scope chip ("Other subnet"/"Network-wide") to the incident strip when the top active incident's netuid differs from the subnet detail page currently being viewed, directly addressing issue #3951's misleading-banner problem. The regex-based path parsing and comparison logic are correct: `currentSubnet` is null on non-detail routes (chip never shows there), and the netuid comparison correctly stringifies for type-safe matching against the route param string. This is a small, self-contained, purely additive UI change with no data-layer or contract impact.

Nits — 7 non-blocking

• No test coverage was added for the new `concernsOtherEntity`/`scopeLabel` derivation logic, which is easily unit-testable given it's pure string/path logic.
• The regex `/^\/subnets\/(\d+)(?:\/|$)/` won't match subnet detail routes using non-numeric slugs (if any exist elsewhere in routing), silently leaving `currentSubnet` null and suppressing the chip — worth confirming `/subnets/$netuid` always resolves to a purely numeric segment.
• Consider extracting the current-subnet-from-path parsing into a small named helper/comment-free util if this pattern is needed elsewhere (e.g. breadcrumbs), to avoid future duplication.
• A brief unit test asserting chip absence on same-subnet incidents and presence for other-subnet/network-wide cases would guard this regression going forward.
• apps/ui/src/components/metagraphed/incident-strip.tsx:57 would benefit from a focused component test covering `/subnets/1` with `top.netuid === 10`, `top.netuid === 1`, and `top.netuid == null` so the new scope labels stay pinned.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#3951
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 (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 109 registered-repo PR(s), 58 merged, 12 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	real-venus; Gittensor profile; 109 PR(s), 12 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: real-venus
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 109 PR(s), 12 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop			—
/	mobile			—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

_{🟩 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

[JSONbored]

Please use the AI skill in the repo when submitting screenshot - it includes instructions for your AI harness to handle the capture and inclusion of this evidence in the exact image sizes / format / layout necessary.

Your images look manually captured and include browser devtools panels, which makes reviewing your changes much harder and far more time consuming, since I can't just tab back/forth between each before and after image, and the images are different sizes so visually, it's much harder for eyes to detect small changes or issues easily.

TL:DR - it makes reviews take a lot longer and more frustrating.

[real-venus]

Please use the AI skill in the repo when submitting screenshot - it includes instructions for your AI harness to handle the capture and inclusion of this evidence in the exact image sizes / format / layout necessary.

Your images look manually captured and include browser devtools panels, which makes reviewing your changes much harder and far more time consuming, since I can't just tab back/forth between each before and after image, and the images are different sizes so visually, it's much harder for eyes to detect small changes or issues easily.

TL:DR - it makes reviews take a lot longer and more frustrating.

I updated the PR description.

[real-venus]

@JSONbored

Please kindly review this.