Use semantic purple for merged pull requests

[Harry19081]

Problem

Merged pull requests reuse the primary blue treatment, so their completed state is visually indistinguishable from ordinary primary actions and links across badges, summaries, sidebar indicators, and merge controls.

Solution

Add a semantic purple scale for light, dark, and high-contrast themes and expose it through Tailwind. Map the shared merged PR presentation to purple, add a merged Button variant with matching split-button interaction states, and use the same semantic status color in detail summaries, action controls, and sidebar indicators.

Potential risks

The new theme variables must remain present in every supported theme; missing variables in a downstream custom theme would cause merged treatments to lose color. Existing open, draft, and closed mappings are unchanged. Manual visual evidence for all three themes is pending, so this PR remains a draft.

Audit

The configured frontend-ui-audit skill file was unavailable at both documented locations. A direct consistency pass confirmed that merged color ownership stays in the shared PR-status and Button primitives, with callers consuming semantic variants instead of duplicating raw color values.

Verification

• Vitest for Button, PR status, session menu builders, and PR detail panel — passed (33 tests across 4 files).
• ESLint on all changed JS/TS/TSX files — passed; tailwind.config.js is ignored by the repository ESLint configuration and produced one warning.
• pnpm typecheck — passed.
• git diff --cached --check — passed before commit.
• Manual desktop verification was not run because local UI control was not authorized for this task.