docs: un-swap the accent colours, which failed both real pairings

[bryanfawcett]

What this changes

Swaps colors.light and colors.dark in docs/docs.json. In Mintlify's
colors block the key names the colour, not the mode: light is the accent
used in dark mode, dark the one used in light mode. They were assigned the
other way round, so both pairings that actually render failed WCAG contrast.

Pairing that renders	Before	After
Accent on the dark ground (#1B1A17)	#8B4513 — 2.45:1 FAIL	#D4A574 — 7.82:1 AAA
Accent on the light ground (#F3F2EE)	#D4A574 — 1.99:1 FAIL	#8B4513 — 6.34:1 AA

docs/README.md gains a short note stating the rule, because the inversion is
counter-intuitive enough that matching key to mode looks like the fix.

Refs #27 — this is item 1 of the two follow-ups that issue was left open for.

Why this way

The palette itself is not in question: both hexes stay, only the assignment
changes. Choosing new colours would have been a bigger change than the defect
warranted, and the brand brown is already primary.

The README note exists because this is the second time this naming has bitten
the repo — the same inversion hit the favicon during the SEO pass. Without it
the next person to read light: #D4A574 against a light-mode screenshot has
every reason to "correct" it back.

It also records why mint a11y is not in the CI gate landed in #28, which
would otherwise look like an oversight: the command additionally measures
dark against the dark background — a pairing that never renders, since
dark is the light-mode accent — so it reports FAIL and exits 1 under any
assignment. Gating it would mean gating on a check that cannot pass.

How it was verified

Computed the four ratios independently first (a WCAG 2.x relative-luminance
script), then confirmed against the tool. mint a11y on this branch:

Light Color (#D4A574) vs Dark Background:  PASS  7.82:1  (meets WCAG AAA)
Dark Color  (#8B4513) vs Light Background: PASS  6.34:1  (meets minimum 3:1)
Dark Color  (#8B4513) vs Dark Background:  FAIL  2.45:1  <- the phantom pairing

Both real pairings went from FAIL to PASS. The residual FAIL is the phantom
cross-check described above and is unchanged by this PR.

Both gated commands pass locally on the pinned CLI (mint@4.2.876), which is
the same version CI installs:

mint validate      -> success build validation passed
mint broken-links  -> success no broken links found

The Docs site job from #28 is the regression guard for the JSON staying
valid; nothing in CI can catch the assignment being wrong again, which is what
the README note is for.

Checks

Docs-only change — no Rust, MCP server, or npm package files are touched, so
the Rust and package gates are not applicable and were not run. CI runs them
regardless.

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-features
• cargo check -p ntl-core --target wasm32-unknown-unknown --no-default-features
• RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --all-features
• Touched mcp/ntl-postgres-mcp-server: not touched
• Touched npm/ntl-cli: not touched
• Commit messages follow the conventional-commit prefixes in CONTRIBUTING.md

Protocol impact

• No normative requirement changed

Presentation only. Nothing in spec/ is read or written by this.

Security impact

• Nothing in spec/threat-model is weakened by this

---

🤖 Generated with Claude Code

https://claude.ai/code/session_0122JtRC4Dbptgefu7QR8gvZ

---

Generated by Claude Code