fix(a11y): compute brand-button text color; fix Create-button flex squeeze

[umzcio]

Stacked PR — depends on #576 and #577.
GitHub cannot base a cross-fork PR on a branch that lives in the fork, so this targets
main directly and its diff currently includes those two PRs' commits. Please merge
#576 and #577 first; this diff will then shrink to just this PR's own 2 commits:
fix(a11y): compute brand-button text color instead of hardcoding black/white and
fix(admin/teams): prevent flex-shrink squeeze on Create/Assign buttons.
The a11y fix touches TeamsTab.tsx, which only exists after #577's decomposition —
hence the dependency.

Summary

Two small UI bugs, both found by using the admin panel rather than reading it, and both
pre-existing (present in Admin.tsx before the decomposition PR this one builds on).

1. Hardcoded text colour on brand-coloured buttons — a WCAG AA failure. Eight sites set a
literal color: '#000' (or '#fff') on a background of var(--highlight-color, #eab308).
Black is correct for the default gold (10.95:1) but inverts for any dark brand colour. On a
deployment with a dark green brand (#1D3C34), black text measures 1.75:1 — below the
4.5:1 AA floor and below even the 3.0:1 large-text floor. White would be 12.01:1.

The correct mechanism already exists and is already used in 37 places:
BrandingContext sets --highlight-text-color from getContrastTextColor(theme.highlight_color)
(frontend/src/utils/color.ts), which flips on luminance. These eight sites simply weren't
consuming it.

2. The "+ Create" button on the Teams page wrapped its label under the icon. It renders
inside <div style={{ display: 'flex', gap: 8 }}> next to <input style={{ flex: 1 }}>, and
set no flexShrink, so it inherited flex-shrink: 1 and was squeezed narrower than its own
content by the growing input. It also used an older inline-flow alignment hack
(verticalAlign: 'middle', marginRight: 4) rather than flex, which is what made it wrappable.

Changes

• Replaced the hardcoded text colour at all 8 sites with
  var(--highlight-text-color, <the previous value>) — keeping the old value as the CSS
  fallback, so a default-branded install renders exactly as before while a branded one picks
  up the computed contrast colour. Sites: TeamsTab ×3 (Create button, Assign button, active
  sub-tab pill), DocumentViewer ×1, AddUrlsModal ×1, DocumentPickerModal ×3.
• Create-team button: added flexShrink: 0, display: 'inline-flex',
  alignItems: 'center', gap: 4, whiteSpace: 'nowrap', and dropped the now-redundant
  verticalAlign/marginRight from the <Plus> icon. This matches the canonical pattern
  already used at QualityTab.tsx:209.
• The neighbouring "Add to Team" button had the same vulnerability and got
  flexShrink: 0, whiteSpace: 'nowrap' — guards only, no flex/gap, since it has no icon.
• utils/color.test.ts: added a regression case asserting
  getContrastTextColor('#1D3C34') === '#ffffff', named for the 1.75:1 failure.

Test Plan

• Shared checks pass (make ci)
• Release check passes if packaging or deployment changed (make release-check) — n/a
• Manually tested the affected feature(s) — verified on a deployment with a dark green brand colour: buttons now render light text on the brand background, matching the rest of the admin surface, and "+ Create" sits on one line
• Updated CHANGELOG.md — not done; an accessibility fix is arguably user-facing. Advise on wording.
• Updated deploy/release docs — n/a

Contrast measured, not estimated:

Background	Black text	White text
#1D3C34 (dark green brand)	1.75:1 ❌	12.01:1 ✅
#eab308 (default gold)	10.95:1 ✅	1.92:1 ❌

No rendering test was added for the layout fix, deliberately. jsdom performs no layout, so
a test asserting "the label doesn't wrap" would pass identically with the bug present. There is
no TeamsTab.test.tsx, and creating one to hold an assertion that proves nothing seemed worse
than no test. If you want real protection for this class of bug, frontend/e2e/ already has 8
Playwright specs and a bounding-box or visual assertion there would actually catch it — happy
to add that if you'd prefer.

One residual, disclosed rather than hidden. DocumentViewer.tsx's CSS fallback remains
#fff, which is itself 1.92:1 on the default gold — so that one site would still fail contrast
on an unbranded install. It is unreachable in practice, since BrandingContext sets the
variable on every app load, which is why it was left rather than changed as a drive-by. Flagging
it so it is a known quantity; happy to correct it in this PR if you'd rather.

Related Issues

Closes #