v1.46.0: full external audit of v1.45.4 — HP-1454-01 … -10

HP-1454-01 (high, release blocker): an uploaded SVG plan opened directly is a
top-level document of Home Assistant's own origin, so a <script> inside it
reaches the session's localStorage and API. Uploading needs write access, which
by default every authenticated user has. SVG responses now carry a sandbox CSP;
only SVG, because a CSP on a PDF can break the browser's viewer and a raster
image has nothing to disable. Verified in Chromium both ways: the script runs
without the header and does not with it.

HP-1454-02: attachment uploads wrote straight to <marker>/<filename>, outside
the config transaction — a cancelled dialog or a rejected save left the stored
url serving new bytes, and every new icon shared one 'new' folder, so two of
them attaching manual.pdf pointed at one file. Uploads take a free name, a new
icon gets a per-dialog staging folder promoted on an accepted save, and
config/set collects superseded and aged-orphan attachments like it does plans.

HP-1454-03: the debounce spaced out the starts of a write, not the writes. A
save slower than 500 ms let the next edit go out with the same expected_rev;
the server accepted the first, rejected the second, and the conflict handler
reloaded over the local copy. Writes are chained now — one in flight, each with
the revision the previous returned.

HP-1454-04: _openPairsCache keyed on room ids and links only, so an aspect
change or a dragged vertex left open boundaries and their glow cuts at old
coordinates. It keys on the rendered model object now — the same invalidation
the model cache already has, not a second strategy. The fingerprint also gained
an O(1) geometry roll-up per room.

HP-1454-05: outer collections were capped, inner ones were not. Limits for
poly points, open_to, controls, pdfs, text and url lengths, plus a total
serialized size cap; legacy  is dropped server-side.

HP-1454-06: upload streams to a temp file and downloads use FileResponse, so a
50 MB manual no longer costs ~100 MB of RSS per transfer.

HP-1454-07: spaceModels() dropped room.settings, so the static card ignored the
per-room fill override. HP-1454-08: layout had no revision on point-wise writes
and no event, leaving static cards stale forever; it now keeps a revision,
returns it and fires houseplan_layout_updated. HP-1454-09: repair cleanup only
walked existing spaces, so a deleted space kept its warning. HP-1454-10:
serialize-javascript pinned past two advisories.

Tests: smoke_svg_sandbox (proves both directions), smoke_config_writer and
smoke_render_parity (both verified failing against a v1.45.4 build), six pure
tests for attachment collection and inner limits, four HA-harness tests for the
CSP, non-overwriting uploads, the size cap and layout revisions.
Docs: CHANGELOG.md + CHANGELOG.ru.md + ARCHITECTURE.md + TESTING.md + STATUS.md.

docs/ARCHITECTURE.md

@@ -172,14 +172,38 @@ double click → properties dialog. In markup mode the "Opening" tool handles cl
 
 | Command | Parameters | Response |
 |---|---|---|
-| `houseplan/layout/get` | — | `{layout: {device_id: {x,y}}}` |
-| `houseplan/layout/set` | `layout` | `{ok}` (admin_only optional) |
-| `houseplan/layout/update` | `device_id`, `pos` | `{ok}` |
+| `houseplan/layout/get` | — | `{layout: {device_id: {x,y}}, rev}` |
+| `houseplan/layout/set` | `layout`, `expected_rev?` | `{ok, rev}` / err `conflict`; event `houseplan_layout_updated` |
+| `houseplan/layout/update` | `device_id`, `pos` | `{ok, rev}`; event `houseplan_layout_updated` |
 | `houseplan/config/get` | — | `{config, rev}` |
 | `houseplan/config/set` | `config`, `expected_rev?` | `{ok, rev}` / err `conflict`; event `houseplan_config_updated` |
 | `houseplan/plan/set` | `space_id`, `ext` (svg/png/jpg/webp), `data` (b64, ≤8 MB) | `{ok, url}` — writes `<space>.<token>.<ext>`, deletes nothing |
 | `houseplan/file/set` | `marker_id`, `filename`, `data` (b64) | `{ok,url,name}` (legacy, WS limit) |
 
+**User content is served inert** (HP-1454-01). An uploaded SVG is the only
+thing here that a browser will happily treat as a *document* rather than an
+image, and it would be a document of Home Assistant's own origin. Inside the
+card that never matters — `<image>` does not run scripts — but the url is
+reachable directly, and uploading needs only write access, which by default
+every user has. `HouseplanContentView` therefore sends a `sandbox` CSP with SVG
+and only with SVG: a CSP on a PDF response can break the browser's built-in
+viewer, and a raster image has no execution model to disable.
+
+**Attachments follow the same commit-scoped lifecycle as plans** (HP-1454-02).
+An upload takes a free name (`unique_filename`) and never overwrites, because
+the bytes under an existing name may be referenced by the stored configuration
+and an upload is not part of that transaction. A new icon has no id yet, so its
+files go to a per-dialog staging folder and move to the real id once the config
+write is accepted — the same copy → save → cleanup order as a rebind.
+`config/set` collects what its commit superseded, and anything unreferenced and
+older than `PLAN_ORPHAN_TTL_S`.
+
+**Config writes are serialized** (HP-1454-03). `_writeConfig()` chains onto a
+single promise: one `config/set` in flight, each carrying the revision the
+previous one returned. The debounce still spaces out *when* a write starts;
+what it cannot do — and used to be relied on for — is keep two writes from
+overlapping, which produced a self-inflicted conflict and lost the newer edit.
+
 **Plan uploads are copy-on-write, and collection belongs to the commit**
 (reviews R2-1, R3-1). The file system is not part of the config's
 optimistic-locking transaction, so nothing referenced may be overwritten or