Serve the pages the panel publishes

The landing was one address. It now also answers on the pages the panel
publishes -- "Sobre nosotros" and the like -- at the addresses the API
itself chooses: `path` and `alternates` put the default language
unprefixed and every other one under its code, so `/sobre-nosotros`,
`/en/about-us`, `/ca/qui-som` are the routes. `core/api.ts#contentRoute`
is the single rule for that shape, and `/es/…` is deliberately not one
of them, so a page has one address rather than two.

Two routes share one load function, because Analog wants a `.server.ts`
beside each `.page.ts`: `[slug]` for the default language, and
`[locale]/[slug]` for the rest.

Whether a slug exists is the API's answer, not something the route table
knows, so the 404 middleware lets page-shaped addresses through and
`ui/content-page.ts` sets the status itself from `ngOnInit` -- the same
`injectResponse()` the landing uses for its 503, and `ngOnInit` because
an input has no value in the constructor. Body HTML comes from the
panel's editor and goes through Angular's sanitiser.

The header shows the featured pages beside the section anchors; the
footer lists them all. On a page the language switcher follows the API's
`alternates`, and a language with no translation leads to the landing in
that language instead of a 404.

Verified: lint, 20 unit tests, build, and 6 e2e -- including a new one
that a page-shaped address the API does not know answers 404 with
`robots: noindex`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -150,8 +150,11 @@ landing/src/
     core/copy.ts           the chrome's own words, in es / en / ca
     core/icons.ts          the icon set, inlined and registered as literals
     core/pi-strings.ts     the strings `@pi/ui` translates on its own
-    pages/(home).server.ts one load function, ten parallel calls
+    core/content-page.ts   the load function both content-page routes share
+    pages/(home).server.ts one load function, eleven parallel calls
     pages/(home).page.ts   the landing itself
+    pages/[slug].page.ts   a page the panel publishes, default language
+    pages/[locale]/[slug].page.ts   the same, in any other language
     ui/                    presentational components, one per payload type
                            (thin wrappers over `@pi/ui`), each with its `.scss`
   server/
@@ -182,7 +185,10 @@ cached maintenance page outlives the maintenance. That status is set from the
 page component through `injectResponse()` (`@analogjs/router/tokens`), which is
 the *render* request's response; the one a page `load` sees belongs to the
 internal request Analog resolves loaders through and never reaches the browser.
-That is also why the 404 status comes from middleware instead.
+That is also why the 404 status comes from middleware instead — except for
+addresses shaped like a content page, where only the API knows whether the page
+exists: the middleware lets those through and `ui/content-page.ts` sets the 404
+itself from `ngOnInit`, once its input has arrived.
 
 **Empty sections disappear**, along with their entry in the nav — a young site
 shows a hero and a contact form rather than eight headings over nothing.
@@ -196,6 +202,18 @@ page cached with `s-maxage` that varied on `Accept-Language` would hand the
 second visitor the wrong language anyway. The switcher in the header is three
 plain links, and `<html lang>` follows.
 
+**Content pages are the exception**, because the API decides their address: a
+page's `path` and `alternates` put the default language unprefixed and every
+other one under its code — `/sobre-nosotros`, `/en/about-us`, `/ca/qui-som` —
+so those are the routes that answer. `core/api.ts#contentRoute` is the one rule
+for that shape; `/es/…` is not one of them, so a page has one address rather
+than two. The switcher on a page follows `alternates`, and a language the page
+has no translation for leads to the landing in that language instead of a 404.
+The same `alternates` become `hreflang` links, with a `canonical`.
+
+Featured pages go in the header after the section anchors; every page is in the
+footer.
+
 ## Rendering and caching
 
 Nothing is prerendered: the page is assembled from content the panel publishes