Update theme generator to use config values for colors

[ruanpepe]

Description

Checklist

• composer check passes locally (Pint + PHPStan + PHPUnit)
• Added/updated tests for the change
• Updated docs in docs/ if behaviour or APIs changed (they are served in-app at /docs)
• Added a CHANGELOG.md entry under [Unreleased]
• New translatable strings added to all 9 locale files in resources/lang/

[puikinsh]

Thanks @ruanpepe — you found a real bug, and the diagnosis was right. Confirmed by rendering the component both ways:

<!-- value="#343a40" -->
<input type="color" name="sidebar_color" value="#0d6efd" class="form-control form-control-color" value="#343a40">

<!-- default="#343a40" -->
<input type="color" name="sidebar_color" value="#343a40" class="form-control form-control-color">

InputColor has no value prop, so it fell through to $attributes->merge() and landed after the component's own value. Browsers keep the first of two duplicate attributes, so all four swatches rendered #0d6efd no matter what the page asked for. default is the right prop.

Digging into it turned up the reason the page needed that fallback in the first place: sidebar_color, primary_color, navbar_color and footer_color were never read by the package, and color_mode was not a config key at all — so the snippet the page told you to paste did nothing. Your config(..., '#343a40') calls would also have quietly broken the moment those keys were added, since Laravel's config() default only applies to missing keys, not to keys holding null.

So rather than merge this and leave the page half-honest, I've landed it as #9, which includes your fix and makes the four keys real — they're now injected into the layout head as CSS custom-property overrides, so the generator's output actually works. You're credited as co-author on the commit.

Closing in favour of #9. Thanks for the report and for iterating on it.