Symptom

MudTabPanel BadgeData chips are visually clipped on their right edge when used on a tab whose text causes the chip to translate beyond the tab's right boundary. Affects every page that uses tab badges, e.g.:

• /admin/connected-systems/{id}/connector-space/{csoId} (Change History tab)
• /t/{type}/v/{id} (Changes tab on the MVO detail page)

The chip's left half and bottom half render correctly; the right ~20% of the circle is sliced off, so the chip looks like a flat-edged D shape instead of a circle.

Root cause (verified via Playwright + DevTools)

MudBlazor v9.4.0 renders MudTabPanel BadgeData via a positioned MudBadge whose default Origin = TopRight. The chip is position: absolute inside .mud-badge-root (its position: relative ancestor) with:

• top: -16px
• right: 0
• transform: translate(50%, -50%) (older versions) / top: -16px standalone (v9.4.0)

The result is that the chip extends half its width past the right edge of .mud-tab and ~half its height above the tab text. Vertically the badge fits within the tab on JIM's pages (we measured top 300.2 inside tab 292.2-340.2), but horizontally the chip overshoots the tab's right edge by 4px (badge right 450.9 vs. tab right 446.9).

.mud-tab has overflow: hidden baked into MudBlazor's CSS — it's there to contain the click ripple animation. That overflow rule clips the 4px overhang on the right edge of the chip.

Why this is hard to fix cleanly

• Setting .mud-tab { overflow: visible } would let the ripple effect spill outside the tab, which is visually worse than a 4px chip clip.
• Setting .mud-tabs-tabbar-content { overflow: visible } (anywhere up the chain) would let badges escape but also break MudBlazor's horizontal tab truncation / scroll-button detection.
• Adding padding-top to .mud-tabs-tabbar-content to push the chip vertically into the box doesn't help here — the overhang is horizontal.
• We tried tab padding-right / chip right overrides — they shift the badge inside the tab, but it then sits awkwardly against the tab text instead of overlapping it the way the chip is designed to.

The cleanest fix would be a fork-only patch to MudBlazor's MudBadge to clip the chip differently when used inside a tab, or to expose Origin / Overlap / Anchor parameters on MudTabPanel BadgeData (currently it has only BadgeData, BadgeColor, BadgeDot).

Workarounds considered

1. Replace BadgeData with inline parenthesised text in the tab title, e.g. Text="Change History (1)". Functional and never clips. Loses the visual badge style.
2. Use BadgeDot="true" for a small dot indicator instead of a number chip. Dots don't have the overhang problem in the same way, but lose the count.
3. File this upstream against MudBlazor.

Diagnostic data

{
  "badge": { "top": 300.234, "left": 430.859, "right": 450.859, "bottom": 320.234, "width": 20, "height": 20 },
  "tab":   { "top": 292.234, "left": 241,     "right": 446.859, "bottom": 340.234, "width": 205.859, "height": 48 },
  "rightOverhang": 4,
  "bottomOverhang": -20,
  "tabbarContent.overflow": "hidden",
  "tab.overflow": "hidden",
  "tabbar.overflow": "hidden"
}

Acceptance criteria

• Tab badge chips render as full circles on the CSO and MVO detail pages.
• No regression to ripple animation containment, tab scroll-button behavior, or rounded tab corners.

References

• MudBlazor v9.4.0 source: MudTabs.razor, _tabs.scss
• Branch where this was investigated: feature/perf-instrumentation-mvo-detail
• Related upstream: MudBlazor #11849, MudBlazor #4724