Plugins page small adjustments & layout shift fix

[a-effort]

🔗 Related Issue

Follow-up to #23, which landed the plugin catalog page. Contributes to #5766, left open on purpose, see Notes.

---

📝 Summary

Polish on the freshly merged plugin catalog, plus one layout bug that turned out not to be plugin-specific.

• Status comes off the cards and the details dialog. status is derived from mode — status === "disabled" iff mode === "disabled" so a Status row next to a Mode row said the same thing twice, and every card rendered the same muted Disabled dot. Design when we can enable to add plugin action.
• The Mode filter comes out of the filters popover as there was only one option so no reason to have a selector. Filters are now hook + tags.
• Opening a dialog or a dropdown no longer shifts the page sideways. One CSS rule in src/index.css; details below.
• Locale cleanup. plugins.catalog.status, .disabled, and .allModes are gone from en-US, and the orphaned .disabled entries in es-ES and pt-BR go with them.

---

📏 Reviewability

• This PR has one clear purpose
• The linked issue is not labeled triage — n/a, this follows a merged PR
• Unrelated bugs or improvements are tracked in separate issues/PRs
• Tests are included with the code they validate
• If AI-assisted, I understand and can explain the generated changes

---

🏷️ Type of Change

• Bug fix (the layout shift)
• Feature / Enhancement
• Documentation
• Refactor (the status and mode removals)
• Chore (deps, CI, tooling)
• Other (describe below)

---

🎯 Why remove rather than fix

Status badges: the gateway exposes no non-admin enable/disable, and status is a restatement of mode. In practice every card rendered a muted grey. Cards stay clean until enable/disable exists, at which point only enabled plugins get status marker(s) a badge.

Mode filter: mode select in the popover carried no distinct use case.

The test fixture's mode moved from "permissive" to "disabled" to match its status: "disabled"

---

🐛 Layout fix

Opening the View dialog shifted the whole page ~7.5px to the left. So did opening the Hook dropdown inside the filters popover: same cause, different primitive.

src/index.css sets scrollbar-gutter: stable on html so pages don't jump when their height crosses the viewport. Radix's dialog locks scroll through react-remove-scroll, which injects at runtime:

body[data-scroll-locked] { overflow: hidden !important; margin-right: 15px !important; }

That margin compensates for a scrollbar it expects to hide — but the stable gutter never releases the space, so it gets counted twice and everything centered slides left by half the scrollbar width. The fix cancels the compensation:

html body[data-scroll-locked] { margin-right: 0 !important; }

The html prefix is load-bearing: the injected rule is also !important and lands later in the cascade, so only higher specificity wins.

Measured in headed Chrome with classic scrollbars, injecting the lock stylesheet the way styleSingleton does at runtime:

	centered element x
unlocked	392.5
locked, before the fix	385.0 (−7.5px)
locked, after the fix	392.5 (no shift)

Reviewers on a trackpad-only Mac will not be able to reproduce this. It needs scrollbars that take up layout space — Windows, Linux, or macOS with a mouse attached. Otherwise the measured gap is 0 and nothing moves.

The rule is global by necessity (the selector targets body), so it fixes every Radix scroll lock, not just the View dialog:

• Dialogs: including the server catalog's new "Add filters" dialog.
• Selects: @radix-ui/react-select mounts RemoveScroll with no enabled guard, so any open dropdown locks scroll. The Hook select inside the plugin filters popover shifted the page the same way, which is the more easily missed half of this bug: the popover opens without moving anything, then the page jumps when you open the dropdown inside it.
• Non-modal popovers don't lock scroll (PopoverContentNonModal skips RemoveScroll), so the filters popover itself was never the trigger.

---

🧪 Verification

Check	Command	Status
Lint	npm run lint	✅
Format	npm run format:check	✅
Unit tests	npm run test	✅ 159 files, 2840 passed, 1 skipped (post-rebase)
Coverage (plugin catalog)	npx vitest run --coverage --coverage.include='src/pages/Plugins.tsx' --coverage.include='src/components/plugins/**'	✅ 97.63% stmts / 91% branches / 99.32% lines

Test changes in Plugins.test.tsx:

• renders plugin cards with status → renders plugin cards without a status badge. It now asserts the description renders and that neither Enabled nor Disabled appears inside the results list, scoped with within(list) so the toolbar's Enabled filter button doesn't match. If someone adds a badge back, this fails and asks to be updated.
• filters by mode and reflects it in the URL → offers no mode filter: hook and tags only, asserting the Hook combobox is present and Mode is not.
• The dialog test gained an assertion that no Status row is rendered, with the mode/status derivation written down next to it.

Coverage stays above the ~95% client-wide target from the acceptance criteria.

---

🎥 Demo

plugins_adjustment.mp4

[gcgoncalves]

Nice cleanup! 🙇

[marekdano]

The PR looks solid good!!!

LGTM 🚀