fix(accent): make the selected-row fill and sidebar grabber follow the accent

[jaywedgeworth22]

What was wrong

The Settings/Console sidebar drew a selected row with the accent for its border but a different token for its fill — and that token was hardcoded to teal:

// QuotaComponents.swift
static let selection = dyn(hex(0x087370).withAlphaComponent(0.12),
                           hex(0x4FD1C5).withAlphaComponent(0.18))

Those are literally AccentChoice.teal's own values. It was the last token in Theme still pinned to teal — accentColor, barRemaining, warning and the rest all read AccentChoice.current. So the moment you picked Violet or Orange you got a violet border sitting on a teal wash.

The same fill backs the Glance header's From Mac / From Fleet toggle, which was labelling its selected segment in the accent colour while filling it teal.

Found alongside it: the sidebar resize grabber hovered in Color.accentColor — the macOS system accent, not the one you picked — so it glowed system blue no matter what you chose.

The fix

selection is now a computed static var derived from the current accent, exactly the way Theme.accent and Theme.barRemaining already work. Same 0.12 light / 0.18 dark alphas, so the fill keeps the contrast it had against the surface. The grabber uses Theme.accent.

Why only two files

Deliberately not GlanceViews.swift — it's contended by open PRs #163 and #175. Fixing the one token corrects both of its call sites without editing a contested file. ConsoleViews.swift is not touched by either open PR.

Verification

• 366 tests pass, 3 skipped, 0 failures.
• The new testSelectionFollowsTheChosenAccentInBothAppearances was checked against the old hardcoded token and fails on every non-teal accent — it read teal 0.031/0.451/0.439 where blue 0.122/0.373/0.749 was expected. So it genuinely pins the behaviour rather than passing by construction.
• Teal is asserted unchanged in both appearances, so the default app looks exactly as it shipped.

Note

This does not add new accent colours — the picker still offers the existing seven. Worth flagging separately: the palette is semantically crowded already (red is danger, amber is warning, teal/green back barRemaining), so adding hues blindly risks collisions between "this is a warning" and "this is a preference". I'd rather extend the palette deliberately than pad it with swatches that blur those meanings.

[kody-ai]

Kody Review Complete

Great news! 🎉
No issues were found that match your current review configurations.

Keep up the excellent work! 🚀

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​

[kody-ai]

The PR body is an agent-written paragraph and the rule explicitly names PR titles/bodies as in scope; GitHub-flavored markdown collapses two literal spaces, so in a chat-rendered PR description the period+ +space pattern is required to keep the two-sentence gap. Replace every single space following a sentence-ending period inside the PR body with .  so the gap survives the GitHub renderer (do not edit the Swift source comments, which are read as files and already use two ASCII spaces).

Kody rule violation: Use two spaces between sentences in every human-facing string and agent-written paragraph