fix(preset-wind4): keep the [color:...] type hint intact when parsing colors - #5299

Description

In preset-wind4, an arbitrary value carrying a color: data-type hint produces no CSS at all for most color utilities:

text-[color:red]          -> (nothing)
text-[color:var(--color)] -> (nothing)
bg-[color:#000]           -> (nothing)
ring-[color:red]          -> (nothing)
outline-[color:red]       -> (nothing)
decoration-[color:red]    -> (nothing)
fill-[color:red]          -> (nothing)

border-[color:*] works, because #5206 made the border rules strip the hint with h.bracketOfColor before reaching parseColor. Every other color utility goes straight to parseColor and silently yields nothing.

Cause

parseColor splits the body on / and : with getStringComponents:

https://github.com/unocss/unocss/blob/main/packages-presets/preset-wind4/src/utils/utilities.ts#L103

getStringComponents defaults its grouping characters to ( and ), so square brackets do not protect their content. For [color:red] the colon is seen at depth 0 and the body is split into ["[color", "red]"]. front is then [color, which cannot match bracketTypeRe, so the type-hint branch immediately below it is unreachable for every bracketed value, and the utility resolves to a color named [color with an opacity of red].

preset-mini does the same split through splitShorthand, which passes '[' / ']' explicitly and is unaffected:

https://github.com/unocss/unocss/blob/main/packages-presets/preset-mini/src/_utils/utilities.ts#L76

preset-wind4 has its own copy of that helper with the same correct arguments at utilities.ts:76, so the two splitters in the same file disagree.

Fix

Pass '[' / ']' to getStringComponents in parseColor, matching splitShorthand right above it. One line.

text-[color:red]          -> color:color-mix(in oklab, red var(--un-text-opacity), transparent)
text-[color:var(--color)] -> color:color-mix(in oklab, var(--color) var(--un-text-opacity), transparent)
bg-[color:#000]           -> background-color:color-mix(in oklab, #000 var(--un-bg-opacity), transparent)

Opacity and interpolation modifiers still compose: text-[color:red]/50 and text-[color:red]:50/display-p3 resolve as expected, and border-[color:*] is unchanged.

Tests

No separate test case. The coverage lives in the shared targets list:

• bg-[color:#000], ring-[color:red], outline-[color:red], decoration-[color:red] and fill-[color:red] added to test/assets/preset-wind4-targets.ts, next to the border-[color:*] entries already there. text-[color:*] is already covered by presetMiniTargets.
• Three entries drop out of the "safe differences" list in the targets test, since text-[color:--variable], text-[color:var(--color)] and text-[color:var(--color-x)]:[trick] now generate CSS.
• test/assets/output/preset-wind4-targets.css picks up the new selectors. The three text- ones merge into the existing rule groups for their untyped equivalents, i.e. they produce byte-identical declarations to text-[--variable] and text-[var(--color)].
• No other snapshot in the suite changes.

Verified by reverting only the source change, rebuilding, and re-running: text-, bg-, outline- and fill- lose their rules entirely, ring-[color:red] falls through to the ring-width rule as calc(red + var(--un-ring-offset-width)), and decoration-[color:red] becomes text-decoration-thickness:red.