V2 (2.4.7-dev.24): color_stops gradient no longer renders — dials fall back to grey (token rename + gradient-group bail)

## Summary
In the **V2 horseshoe rewrite (2.4.7-dev.24)**, horseshoes that colored correctly on stable **2.4.7** render **flat grey** — the `color_stops` gradient is no longer applied to the state arc. There are two compounding causes.

## Environment
- flex-horseshoe-card **2.4.7-dev.24** (V2 engine)
- Same card config renders correctly on stable **2.4.7**
- HA served via HTTPS; reproduced in Chrome, Edge and incognito

## Symptom
A horseshoe with `color_stops` + `horseshoe_style` gradient shows the configured `horseshoe_state.color` grey instead of the color-stop gradient.

**Before — stable 2.4.7 (colored):**

**After — 2.4.7-dev.24 (grey):**

## Cause 1 — style token renamed, no backward-compat
Stable accepted `show.horseshoe_style: linear_gradient` (**with** underscore). V2 only matches the **no-underscore** tokens. In `src/horseshoe-state.js`:
```js
const bidirectionalGradient =
['autominmax', 'minmaxgradient', 'lineargradient'].includes(show.horseshoe_style) // 'linear_gradient' no longer matches
```
and again in `src/horseshoe-renderer.js`:
```js
if (runtimeConfig.show?.horseshoe_style === 'minmaxgradient'
|| runtimeConfig.show?.horseshoe_style === 'lineargradient') { ... }
```
So an existing `linear_gradient` config silently fails the gradient branch → no gradient is built → the arc falls back to `horseshoe_state.color`. There's no alias or migration from the underscore form, and no warning.

## Cause 2 — gradient still not applied even with the corrected token
After changing the config to `lineargradient`, the arc is **still grey**. `updateStatePathElements()` in `src/horseshoe-renderer.js` returns early when the gradient group element can't be found:
```js
const gradientGroup = root.getElementById?.(
`horseshoe-state-${cardId}-${horseshoeIndex}-${gradientStyle}-group`
) ?? root.querySelector?.(`#horseshoe-state-${cardId}-${horseshoeIndex}-${gradientStyle}-group`);

if (!gradientGroup) {
return; // <-- arc keeps its non-gradient fill (horseshoe_state.color, e.g. #AAAAAA)
}
```
The gradient group is evidently not created during initial render for this (valid) bidirectional `lineargradient` + negative-scale config, so the state arc renders flat grey.

## Reproduce
Minimal config — bidirectional gradient over a negative-to-positive scale:
```yaml
type: custom:flex-horseshoe-card
entities:
- entity: sensor.some_power # any numeric sensor spanning the scale
show:
horseshoe_style: lineargradient # also fails as `linear_gradient` (Cause 1)
horseshoe_scale: { min: -23, max: 23, width: 6, color: '#DDDDDD' }
horseshoe_state: { color: '#AAAAAA' }
color_stops:
-20: '#00FF00'
5: '#00FF00'
10: '#FFFF00'
20: '#FF0000'
```
**Result:** grey arc on 2.4.7-dev.24. The identical config renders the green→yellow→red gradient on stable 2.4.7.

## Suggested fixes
1. **Backward-compat:** accept `linear_gradient` as an alias for `lineargradient` (and normalize any other renamed style tokens), or emit a config-migration warning when the old spelling is seen.
2. **Gradient group:** ensure the `…-${gradientStyle}-group` element is created during the initial render for bidirectional `lineargradient` configs, so `updateStatePathElements()` finds it instead of bailing to the flat `horseshoe_state.color`.

_(Filed alongside the separate cost-doubling fix in #490, which is what surfaced this while comparing 2.4.7 vs 2.4.7-dev.24.)_