Fix dark mode option styling inside select optgroups

[760524mkfa00]

The scenario

A native <flux:select> with its options organised into <optgroup>s, viewed in dark mode on Windows.

<flux:select placeholder="Select a school...">
    <optgroup label="Elementary">
        <flux:select.option value="1">Alpha Elementary</flux:select.option>
        <flux:select.option value="2">Bankhead Elementary</flux:select.option>
    </optgroup>
    <optgroup label="Senior">
        <flux:select.option value="3">Beta Secondary</flux:select.option>
    </optgroup>
</flux:select>

The problem

The default variant forces dark mode option colours with a child combinator:

// Options on Windows don't inherit dark mode styles, so we need to force them...
->add('dark:[&>option]:bg-zinc-700 dark:[&>option]:text-white')

&>option only matches options that are direct children of the <select>. Wrapping them in an <optgroup> drops them a level, so they match neither rule and fall back to the browser's default light mode option rendering — the same problem #1100 fixed, one level down.

The result is an inconsistent dropdown rather than a uniformly wrong one: a placeholder is emitted as a direct child of the <select>, so it keeps its dark styling while every grouped option below it does not.

The solution

Match the options as descendants instead:

- ->add('dark:[&>option]:bg-zinc-700 dark:[&>option]:text-white')
+ ->add('dark:[&_option]:bg-zinc-700 dark:[&_option]:text-white')

Same specificity, strictly wider match, so ungrouped selects are unaffected.

No dist rebuild is needed — these utilities are generated in the consuming app via the @source on flux/stubs, and dist/flux.css contains no option utilities of its own.

Notes

The <optgroup> label itself is still unstyled in dark mode and wants its own rule, something like dark:[&_optgroup]:bg-zinc-700 plus a muted label colour. I've left that out because the right colour is a design decision rather than a bug fix, and I didn't want to bundle a judgement call with a one-line correction. Happy to add it if you tell me what you'd want.

This also affects #2693, whose default group variant renders a plain <optgroup>. The screenshots on that PR look like the custom/pro variant, which is probably why it hasn't surfaced there.

Fixes #2720

[calebporzio]

Thanks!