[kbaker827]

Fixes #97

Summary

The action editor can deliver an unquoted y: 10 as true: 10 (visible in the YAML in #108 and in the comments on #97), so the element reached the renderer with no y: text stacked at the top, and elements that require y failed. This renames that key back to y during validation. An explicit y wins if both are present, and values of true under other keys are untouched.

A comment on #97 says dlimg failed even with a quoted y. I couldn't reproduce that: the real renderer draws a dlimg correctly when it has a y, using a data URI source.

Only top-level element keys are repaired, which is where the renderer reads y.

Test plan

• New tests for the boolean and string key forms, failed before the change
• Full suite passes. Run locally on Windows with small local stand-ins for the Unix and BlueZ modules Home Assistant needs (not part of this PR), so CI on Linux is the first clean run.
• Not reproduced in the Home Assistant frontend itself: please confirm in Developer Tools

This and the #140 PR both append tests to the end of tests/test_services.py, so whichever merges second has a small conflict to resolve (keep both blocks).

🤖 Generated with Claude Code

[kbaker827]

CI is waiting on maintainer approval here, so I ran the workflows on my fork at 8110c5c:

• Tests: passed, on both the latest and min-ha Home Assistant, plus ruff
• hassfest: passed
• HACS: 8 of 10 checks passed. The two failures are fork settings (issues disabled, no topics), and the fork's unmodified main fails the same two.

This covers this branch on its own, not merged with the other open PRs, and nothing has been run on real hardware.