feat(sandbox): add standalone interactive test sandbox with prototype overrides

[10tribu]

Introduce a self-contained developer sandbox under sandbox/ to test and
preview the Helios custom card locally with simulated Home Assistant states,
without modifying any production files in src/ or dist/.

What this adds:

1. Interactive Sandbox Environment (sandbox/):

   • sandbox/index.html: Responsive preview stage (Desktop, Tablet, Mobile)
     with collapsible sidebar controls.
   • sandbox/sandbox.css: Theme-aware styling (dark / light toggle).
   • sandbox/mock-hass.ts: Realistic HassMock state manager simulating solar PV,
     battery SoC/power, grid import/export, and weather conditions.
   • sandbox/sandbox-app.ts: Orchestrator with Card Settings, Live Simulation,
     and YAML editor tabs.

2. Experimental Prototype Overrides (Non-intrusive):
   All features are implemented as runtime overrides in sandbox-app.ts
   leaving src/ and dist/ 100% untouched:

   • arc-zoom: Dynamic scaling of the sun/moon arc radius ([0.25, 2.0]).
   • Continuous scene-zoom: Smooth continuous zoom ([0.25, 2.0]).
   • battery-above-arc: Shadow DOM CSS elevation of chips/pills over the 3D arc.
   • Miniature tilt-shift / vignette overlay.
   • sandbox/git-changes.patch: Reference patch showing direct src/ implementation.

How to test:

1. Run npm run dev
2. Open http://localhost:5173/sandbox/

[ReikanYsora]

Hi Christophe,

Well, it's a big PR! I went through the whole thing this evening, the sandbox and the patch you put next to it, and I want to give you a proper answer rather than a quick one, because there is real work in there and a couple of things I genuinely want to keep.

Let me start with the one that made me smile: you found a bug. shadow-opacity and shadows-enabled are missing from VISUAL_CONFIG_KEYS, and my old comment right above that list says it must be exhaustive. Nobody had noticed because Home Assistant's editor recreates the card on every change, so the engine always boots with the fresh config and the gap never shows. In your sandbox the element persists, and there it does.
That is exactly the kind of thing a tool like yours is good at surfacing.

Now the honest part. I can't merge the PR as it stands, and I'd rather explain why than leave you guessing :/

The first reason is that the interesting content lives in git-changes.patch, and a patch file committed to the tree is something no tool can look at: the CI doesn't run it, the tests don't see it, and in six months nobody will know whether it still applies. The changes it describes need to be real changes, each on its own, so they can be judged, tested and documented one at a time.

The second is that the patch mixes things of very different nature. The shadow keys are a fix. arc-zoom, a continuous scene-zoom and battery-above-arc are new options, and those are product questions before they are code: the arc is sized automatically to fit the card on purpose, the three zoom steps were a deliberate choice, and I'm about to open a whole release ("Your Own Rules", #391) on what should and shouldn't be configurable around the chips. I'd like each of those to be its own issue, so I can weigh them for what they are and you can make the case for each. Some of them may well end up in the card; I just don't want to decide that inside a PR about a sandbox.

And there is one I have to say no to, and I want to be clear about the reason because it's a principle rather than a taste. applyCodeImpliedWeather fills in precipitation, snowfall and cloud cover from the WMO code when no sensor provides them, so that rain falls on the scene when the weather entity says "rainy". I understand the intent completely, the scene staying dry under a rainy forecast looks wrong. But Helios never shows a number it made up: every value on the card is either measured or comes from the weather model, and 12 mm/h derived from a label is neither. If the model says no rain and the entity says rain, the right fix is upstream, in what feeds the card, not a synthetic value painted over the model. So that part won't go in, in this form or another :/

About the sandbox itself. You may not have seen it because it lives in another repository (my website), but the website already has one: demo-mount.js in helios-ha-website mounts the real card on a mocked hass, and it's what I use for visual checks (I used it again this afternoon for a pixel comparison). Two mocks would be one too many for me to maintain (I have already a lot of things to maintain actually). The other thing that holds me back is the technique: patching HeliosEngine.prototype and reaching private fields through as any is fine for a throwaway tool, but once it's in the repository the engine has a second consumer of its internals that will break silently the next time I move something.
If you'd like a sandbox to live here, I'd take one that mounts the card without "monkey-patching", passes the repo's lint, and follows the house style (Allman braces, //comment without the space, ASCII only). That's a smaller, calmer tool than the one you built, but one I could keep alive. And yeah, I know, no web-developer use Allman style but... I'm not a web developer :D

So, concretely, two ways forward, and you pick. Either you split this into three: a PR with the shadow keys fix plus a test, one issue per proposed option so I can look at each on its own, and, if you want, a slimmed-down sandbox PR along the lines above. Or, if you'd rather not spend more evenings on it, I do the split myself: I take the shadow fix into 2026.9.5 right away and open the issues from your descriptions, and every piece that comes from your work is credited to you, in the commit and in the changelog, as the contributor it came from. Just tell me which you prefer :)

Either way, thank you very much for digging into the card that deeply, it's a incredible work.

Cheers ;)

ReikanYsora / Jérôme