Consolidate “chip” UIs into a single, reusable component

Context
Chips (those little rounded pills that show tags, filters, project names, scopes, etc.) appear in four separate areas today:

1. the Publish Template flow (template tags)
2. the Credential-permissions dialog (project names)
3. the History page (active filters)
4. the OAuth Client editor (granted scopes)

Each screen ships its own implementation and its own styles. Unsurprisingly, the visual treatment and behaviour of chips now diverge, and any tweak requires touching four code paths.

Why this matters
Maintaining multiple variants for the same UI element is costly:

• Inconsistent look-and-feel chips away at perceived quality.
• Design tokens evolve, but updates never propagate everywhere.
• Bug fixes get duplicated (or forgotten) across implementations.

Objective
Create a single chip component that every screen can import. The component must be flexible but opinionated, exposing only the options we actually need:

• Appearance — choose among a small set of colour variants (default / success / warning / danger) and two sizes (regular, small).
• Behaviour — static or “dismissible” via an × button; optional click handler.
• Accessibility — proper aria-labels, focus ring, and keyboard removal for dismissible chips.

Once the new component lands, migrate the four existing screens so they all render chips through this shared API. From that point on, any future feature that needs chips will rely on the same component.

Done when

• The only chip-related code lives in components/chip.ex (or similar).
• All four screens render visually identical chips and retain their current UX (adding, removing, filtering, etc.).

Centralising chips will give us a single source of truth for thid UI element in the app, cutting design drift and maintenance overhead.

Screenshots