fix: match docs content column background to page background

[keye-maker]

What

The docs content column had an unexpected blue-ish cast compared to the rest of the page (most visible on the Repository configuration page, but it affects every page).

Root cause

The willow theme paints the main content column (the direct child of #content-area) with its own neutral gray dark:bg-gray-900 (#161616). That neutral surface sits inside the warm page background configured in docs.json — background.color.dark → #181611 (--background-dark = 24 22 17). A neutral-gray surface framed by a warm one reads cool/blue-ish (and its blue channel, 22, is literally higher than the frame's, 17).

This is not page-specific — the content column and frame colors are identical on every page; the config page just made the contrast easy to notice.

Fix

Pin the content column to the configured page background so the content area and the frame are one continuous warm tone:

.dark #content-area > div {
  background-color: rgb(var(--background-dark)) !important;
}

• Scoped to #content-area's direct child so other bg-gray-900 surfaces (cards, etc.) are untouched.
• References the --background-dark variable rather than a hardcoded hex, so it tracks any future change to background.color.dark in docs.json.

Verification (computed colors via browser)

• Content column: rgb(24,22,17) == frame rgb(24,22,17) ✅
• Code blocks: rgb(11,12,14) unchanged ✅
• Other bg-gray-900 elements: unchanged ✅

🤖 Generated with Claude Code

[TheMythologist]

I'm not sure if it's just dev vs prod, but for some reason this change made the scrollbar in the side menu appear.

Dev:

Prod:

[keye-maker]

Thanks for catching this! I had Claude dig into it:

Claude:

The sidebar scrollbar isn't caused by this change.

This PR only sets a background-color on #content-area > div. The sidebar (#sidebar) lives outside #content-area, and background-color doesn't affect layout, so it can't introduce an overflow there.

I verified by measuring the sidebar's nav scroll container at the same viewport (1280×720) on both branches:

	scrollHeight	clientHeight	overflows
this branch	1120	548	yes
main	1120	548	yes

Identical — the nav content (1120px) is taller than its viewport area (548px) on main too, so the scrollbar is already there without this change.

As you suspected, it's a dev-vs-prod difference: mintlify dev shows a persistent scrollbar, while the production build hides it.