chore(release): re-cut as 1.0.14 so the add-on sees an update

[cayossarian]

Why

#36 and #37 both merged carrying version 1.0.13.

The add-on image tag is derived from span_panel_simulator/config.yaml (see the Extract version from config.yaml step in build-addon.yaml), and the build workflow fires on every push to main touching src/**, pyproject.toml, or span_panel_simulator/**. So:

1. fix(clone): read circuit energy seeds in the enclosure reference frame #36 merged → image published as 1.0.13 (circuit-energy fix)
2. feat: vendor the flat emitter, fixing an add-on image that could never start #37 merged → image rebuilt and overwrote the 1.0.13 tag (vendoring)

Anyone who pulled 1.0.13 between the two merges holds the circuit-energy fix but not the vendored flat emitter — and Supervisor has no version change to prompt on, so they never get it. That matters more than usual here, because the vendoring is the fix for an add-on image that could never start.

What changed

• All four version references bumped to 1.0.14 (pyproject.toml, __init__.py, config.yaml, Dockerfile — kept in step by the sync-version pre-commit hook).
• The vendoring changelog entry, already the topmost, relabelled 1.0.13 → 1.0.14, with a short note recording why.
• The circuit-energy entry keeps 1.0.13 — that is the version its image was actually published under, so the history stays truthful.
• uv.lock refreshed; it still recorded 1.0.13.

Verification

• 395 tests pass
• ruff check clean, mypy --strict clean across 85 source files
• pre-commit hooks pass, including sync-version

Worth considering separately

The collision was structural, not a slip: two branches cut from the same base each bumped to the next patch version, and nothing rejected the duplicate at merge time. A CI check that fails when config.yaml's version is not greater than the version on main would catch it at PR time rather than after publish. Happy to add that if you want it.