Should WidgetPicker's header default to a brand fill, so consumers get tenant branding without passing headerBackgroundColor/headerTextColor?

Question, not a bug report

WidgetPicker already supports a branded header - headerBackgroundColor and headerTextColor are in its signature. The question is whether the default should be branded, so every consumer gets tenant branding without passing them.

What the defaults are today

From the built @sistent/sistent@0.22.6 bundle:

({ widgetsToAdd, onAddWidget, onClose, headerBackgroundColor, headerTextColor, containerSx = {} }) => {
  ...
  background: headerBackgroundColor || theme.palette.background.default,
  color:      headerTextColor      || theme.palette.text.primary,

So the header falls back to background.default / text.primary - near-white on near-black in the installed light palette.

Why it came up

Layer5 Cloud migrated its dashboard onto DashboardLayout + WidgetPicker (layer5io/meshery-cloud#5992), replacing a bespoke drawer whose header painted with background.brand?.default ?? primary.main and text.inverse. Because background.brand.default is an org-theme token, that header carried the tenant's brand colour; the component default does not, so the panel went near-white for every tenant.

Cloud is passing the two props to restore it, which is using the component's API rather than overriding it - no change is needed in Sistent for that consumer to be correct, and this issue is not blocking that PR.

The actual question

For a panel that is chrome rather than content, is the near-white default the intended design-system look, or should WidgetPicker default its header to background.brand?.default ?? primary.main with text.inverse?

Two things point at the latter being worth considering:

• Every consumer that wants tenant branding has to pass two props and know to, and a consumer that simply does not know will silently ship an unbranded panel. That is the failure mode Cloud just hit.
• background.brand.default is already theme-resolved per organization, so a branded default costs a consumer nothing and still respects whatever theme is installed.

The counter-argument is equally reasonable: a light header may be the deliberate treatment for a side panel, and brand fill may belong only where a consumer asks for it.

Whichever way it goes, it would help to say so in the component's docs, since today the default is discoverable only by reading the bundle.

Related: layer5io/sistent#1843 (DashboardLayout sizing its sticky sidebar from sidebarHeight independently of sidebarTopOffset).

Start with the built @sistent/sistent@0.22.6 WidgetPicker implementation and compare its current header fallback with the component API. Resolve whether the default should remain neutral or use the theme's brand and inverse tokens, then document the chosen default and verify the consumer-facing behavior.