Consolidate duplicate UI primitives: SettingsSwitch, MCP form segments and the two inline notices

Problem

Three kinds of control each have two or more implementations that look and behave differently for the same job:

SettingsSwitch vs Switch (audit F-04). apps/web/src/panels/SettingsSwitch.tsx:27 has no hover area. It dims when disabled with opacity-50 and ignores reduced motion. Its ring-primary focus ring sits flush on a bg-primary track, so you can't see focus when it is on. It still has 14 call sites in 11 Settings pages, while the Extensions, MCP, Pi packages and Search pages use packages/ui/switch.tsx. The result is two switch looks in one dialog. apps/web/src/styles/buttonUsage.test.ts:147-151 says the merge is "tracked separately", but no issue tracks it.
ToggleSegment used as a form control. apps/web/src/panels/McpServerDialogs.tsx:159-186 builds a local Segments set from ToggleSegment for form values: transport :316, exposure :380, tier :732, scope :741. These have no radio semantics, one Tab stop per option and no group name. Settings forms use SegmentedControl for the same kind of choice.
SettingsNotice vs StaleComposerNotice. apps/web/src/panels/SettingsNotice.tsx:12-26 uses a borderless control-bg surface, no live region and RiCheckLine for success. packages/resource-renderers/src/renderers/StaleComposerNotice.tsx:7-11 follows the Notices pattern: elevated fill, severity border, role="status". apps/web/src/styles/NOTIFICATIONS.md:24-29,42 asks for that pattern and RiCheckboxCircleLine.

Move the SettingsSwitch call sites to Switch (onChange becomes onCheckedChange; check row alignment, since its hit area is 24px). Delete SettingsSwitch and its test, and remove the exemption.
Replace MCP Segments with SegmentedControl, named by its field label.
Decide on one inline-notice surface; this is a design call. Put it in a packages/ui primitive that both apps/web and resource-renderers can import, and render both notices through it.

Found while documenting the component library in #1075.