Reduce rounded corner radius for markdown dropdown bars and atom cards

[FadhlanR]

Reduces the corner radius by 2px on the RichMarkdown editing UI surfaces that read a touch too rounded, and tightens the mode-switcher menu row height.

Changes (CSS-only)

• Mode-switcher dropdown (markdown-editor-mode-select.gts) — trigger bar and open menu corners 10px → 8px, via a locally-scoped --boxel-form-control-border-radius override that cascades to BoxelSelect's trigger/menu rules.
• Menu rows — reduced vertical padding (--boxel-sp-xxs → --boxel-sp-3xs) so the dropdown reads less tall.
• Atom card pill (codemirror-editor.gts, .codemirror-card-slot--inline) — corners 10px → 8px.

Scope

Everything is scoped to the Markdown editing UI. No global tokens change, so other selects, buttons, and inputs keep their current radius.

Testing

• Existing rich-markdown-field-test.gts integration tests assert class/attribute presence and interactions (not computed styles), so they're unaffected.
• Visual confirmation against the ticket mocks still pending.

Closes CS-11696

[github-actions]

Host Test Results

    1 files      1 suites   2h 52m 18s ⏱️
3 809 tests 3 795 ✅ 14 💤 0 ❌
3 828 runs  3 814 ✅ 14 💤 0 ❌

Results for commit fbea771.

[FadhlanR]

[Claude Code 🤖] Review lens: this is a CSS-only tweak that rides on a design-token override, so the review focused on (1) whether the token override actually reaches both surfaces it claims — the trigger and the separately-rendered dropdown, (2) whether anything else derives from the old radius and would now visually drift, and (3) whether a twin implementation of the atom pill exists elsewhere that this change misses.

Bottom line: no blocking issues. Every mechanism the change relies on checks out, and the change matches the design annotations (reduced rounding on the mode-switcher trigger and menu, shorter menu rows, reduced rounding on the atom pill) — so the "visual confirmation pending" item in the description should close after a quick eyeball in the app.

What lands right

• Overriding --boxel-form-control-border-radius locally instead of hardcoding 8px keeps the value derived from the base token, so a themed --boxel-border-radius still flows through (and a sub-2px themed radius is safe: the negative calc result clamps to 0 at used-value time). I checked the token's other consumers (input, multi-select, input-group, card-container in boxel-ui) — none can see this override, so the scoping claim in the description holds.
• Twin check came back clean: the preview/saved markdown renderer (packages/base/default-templates/markdown.gts) puts no pill chrome on .markdown-bfm-card-slot--inline, and the default atom template renders bare text — the pill exists only in the compose-mode editor, so there is no second pill rule to keep in sync.
• The hover overlay ring around atom cards follows automatically — detail in the inline comment on codemirror-editor.gts.

Non-blocking recommendations

1. Consistency decision worth making deliberately: the other floating panels in the same editor — the card-search popup (.codemirror-card-search) and the format picker (.codemirror-format-picker) in codemirror-editor.gts — keep the full --boxel-border-radius. If the design intent generalizes to "this editor's floating chrome is 2px tighter", that's a natural follow-up; if the intent was only the two annotated surfaces, nothing to do.
2. The "base radius − 2px" decision is now written in three places (trigger token, dropdown token, atom pill). Fine at this size; if it spreads to a fourth site, promote it to a single component-level custom property.

Adjacent, out of scope

• The atom pill's colors use numbered palette tokens with hex fallbacks (--boxel-100, #f0f0f0 / #c4c4c4) rather than the semantic role tokens (--muted, --border) the styling conventions call for. Pre-existing, not this PR's problem — flagged for whoever touches the pill next.

[FadhlanR]

[Claude Code 🤖] Confirmation — this second token override is required, not redundant. It can look like the trigger-side --boxel-form-control-border-radius in the scoped block above should cover the menu too, but it can't reach it, for two reasons verified in packages/boxel-ui/addon/src/components/select/index.gts:

• BoxelSelect's syncCustomProps() does copy --boxel-form-control-border-radius from the trigger's computed style onto the dropdown container — but startObservingTheme() early-returns when @renderInPlace is true (as it is for this select), so that JS sync never runs here.
• With renderInPlace, the dropdown content renders as a sibling of the trigger element (which is what carries .markdown-editor-mode-select), not a descendant, so the custom property can't cascade into it either.

So this rule is the only path by which the menu's border-radius: var(--boxel-form-control-border-radius) (the .boxel-select__dropdown rule in select/index.gts's global style block) sees the reduced value. Setting it on the dropdown element itself also correctly beats both the :root default in variables.css and any CardContainer ancestor that re-sets the token, because a rule matching the element wins over inherited values.

This also stays correct if the select ever stops using renderInPlace: syncCustomProps would then copy the trigger's computed value — the same reduced radius — onto the portal'd dropdown as an inline style, so the two mechanisms agree. Nothing to change.

[FadhlanR]

[Claude Code 🤖] Confirmation — the specificity claim in this comment checks out. BoxelSelect's default row padding (padding: var(--boxel-sp-xxs) on .boxel-select-option-item in packages/boxel-ui/addon/src/components/select/index.gts) lives in a <style scoped> block, so glimmer-scoped-css rewrites it with a scoping attribute selector — effective specificity (0,2,0), which this (0,3,0) rule beats regardless of stylesheet order. The state-variant rules that do reach (0,3,0) after the rewrite (--selected, --highlighted) only set colors, never padding, so there is no order-dependent tie. Using padding-block (rather than the full shorthand) also correctly leaves the horizontal padding at the shared default. Nothing to change.

[FadhlanR]

[Claude Code 🤖] Confirmation — the hover overlay ring follows this change automatically. The overlay that draws the outline around a hovered atom (packages/host/app/components/operator-mode/overlays.gts, the offset middleware) mirrors getComputedStyle(reference).borderRadius from the registered card element onto the floating overlay, and this slot span is that reference (it carries context.cardComponentModifier). So the ring tracks the reduced radius with no host-side change needed — the two won't drift.

Two small notes, neither blocking:

• In a context where --boxel-border-radius is undefined, the fallback math lands at calc(4px - 2px) = 2px — proportionally a much bigger cut than 10px → 8px. In practice the token is always defined via boxel-ui's variables.css, and keeping the 4px fallback matches this file's convention, so this is fine as written.
• If a theme sets --boxel-border-radius below 2px, the calc result goes negative and CSS clamps it to 0 at used-value time, so there's no invalid-declaration fallout.