write down that addresses are never localised

Localisation stops at the words around the content. No path segment is
translated: reserved segments stay `page` and `tags` in every language, page
numbers stay ASCII, and a variant is reached at the English key under its prefix.
The theme contract gains the matching rule — a URL, key or path segment must
never go through `t`, `num` or `day`.

This is already how the code behaves; every localisation function lives in
internal/render/chrome.go and the content package, which owns every URL, cannot
reach it. Recorded because nothing in the code says so out loud.

state.md now names the five frontmatter keys the parser actually lifts, so
content-model.md's table reads as the accepted format rather than a list of what
runs — `slug` in particular is unread today.

docs/content-model.md

@@ -143,6 +143,12 @@ published URL never changes meaning; renames add `aliases` and emit permanent re
 bundle between sections changes the URL the engine emits, and the old path resolves only through
 `aliases` — so a section list is effectively permanent once anything is published.
 
+**No path segment is ever localised.** Reserved segments stay `page` and `tags` in every language, page
+numbers stay ASCII digits, and a slug is whatever the key says: `/bn/lekha/page/2/`, never a translated
+spelling of it. Localisation is for the words around the content, never the address of it (ADR-0034). A
+Bengali variant is therefore reached at the English key under a prefix — `/bn/posts/hello-world/` — and
+the only thing that can change a variant's path is a `slug` override, which the parser does not read yet.
+
 A language prefix wins over a section of the same name, so a site with Bengali content may not also have
 a section called `bn`. The engine treats a leading segment as a language only when some bundle is written
 in it.