Let the owner change the name, the icon and the dates

Three things that needed a rebuild and a redeploy, or had no way in at all, now
have a Site identity panel in the admin: the restaurant's name and tagline, an
SVG icon upload, and a switch for whether a menu says when it was published.
They live in data/site.json and data/brand/icon.svg, extending ADR 0007: what
the owner changes is content, and the config is the seed plus the theme, which
still needs a rebuild.

An uploaded SVG is a document that would run with this origin's authority, so it
is reduced to shapes on the way in and served with default-src 'none'. The
archive list keeps its dates even when the switch is off, because those dates
are how one old menu is told from another.

Also fixes the live check's own trap: the app caches identity in memory, so the
tests drive it through the app rather than a second store instance, which would
be a second writer.

docs/adr/0008-site-identity-is-content.md

@@ -0,0 +1,5 @@
+# The restaurant's name, tagline and icon are content
+
+Changing the name of the restaurant used to mean editing `config/<site>.site.json`, rebuilding the image and redeploying. The name, tagline, icon and the switch for showing published dates now live in `data/site.json` and are edited in the admin, extending ADR 0007's split: what the owner changes is content, and the config is only the seed plus the things that need a rebuild (the theme).
+
+**Consequences**: an uploaded SVG is served from this origin, so it is reduced to shapes on the way in (no script, no event handlers, no remote references) and served with `default-src 'none'`; the icon's URL is fixed at `/brand/icon.svg` so replacing it does not invalidate anything cached elsewhere. Because the app holds the identity in memory, a hand-edit of `data/site.json` on the server is not picked up until the container restarts — the admin is the supported way in.