feat(marketing): phase 4 — the marketing pages

PLAN.md §13 phase 4: /features/, /architecture/, /modules/, /integrations/, and
/community/ — plus the two scope items the phase table never assigned to anyone.

Six decisions taken by the org lead before coding, recorded in PLAN.md §10 as
D20-D25:

- D20 /features/ is the homepage's list with a `detail` line, not a second list.
  One data file, two renderings, so they cannot disagree about what exists.
- D21 /architecture/ draws reasons, not reference: three new inline SVGs, one per
  boundary. No endpoint tables, no config keys — those are phase 8's and stay
  canonical in docs/.
- D22 The deliberate absences of §2 become one tagged data file, rendered on the
  three pages that promise them.
- D23 Phase 4 absorbs /community/ (specified in §10 and §14 N3, linked from the
  header since phase 1, built by no phase) and checkLinks.mjs.
- D24 `needsModule`: writing the Teams detail exposed a false claim phase 3
  shipped. Teams are module-sourced only — teams.module_id is NOT NULL, there is
  no create route, sync is gated on providerModuleId() — so the Community group
  no longer says a bare core does all of it.
- D25 The per-capability demo affordance brand.json had promised since phase 2 is
  a deep link, filled at boot from data-demo-path.

checkLinks.mjs reads the built HTML rather than src/, because half these links
are assembled from data files and template literals. Its PLANNED_ROUTES list is
checked in both directions, so it cannot rot into a permanent exemption.

applyBrand.mjs gained a pass that recomputes deep links from their immutable
path, making it idempotent and reversible; checkBrand.mjs lifts that pattern out
and runs it against the stock markup so the two cannot drift. Both proved
against a real mount, in both directions.

Fixes a cascade bug the checks could not see: [data-demo-url=''] and a scoped
component class are both specificity 0,1,0, so .demo-link's `display` beat the
hide rule and twelve links to a nonexistent demo rendered, each resolving to the
current page. The rule is now !important.

The four diagrams' shared SVG vocabulary moved to src/styles/diagram.css.

Verified from a clean checkout: npm ci, all five checks, astro check (0 errors),
production build, and a live browser pass at desktop and 390px.

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

src/pages/features.astro

@@ -0,0 +1,223 @@
+---
+import Base from '../layouts/Base.astro';
+import PageHeader from '../components/PageHeader.astro';
+import NotBuilt from '../components/NotBuilt.astro';
+
+import platform from '../data/platform.json';
+import {
+  capabilityGroups,
+  assertCapabilityCoverage,
+  assertDetailCoverage,
+} from '../data/capabilities.mjs';
+
+/**
+ * `/features/` — PLAN.md §13 phase 4, built to D20.
+ *
+ * ---------------------------------------------------------------------------------------
+ * THE SAME LIST THE HOMEPAGE HAS, WITH THE ARGUMENT ATTACHED
+ * ---------------------------------------------------------------------------------------
+ * D18 put all five groups on the homepage named only, and left the per-capability argument
+ * here. This page is therefore not a second list: it is the same `capabilities.mjs` data
+ * rendered with the `detail` line the homepage drops. That is the whole of D20, and it is
+ * what makes "the site advertises something that was removed" a build failure rather than
+ * a thing somebody has to notice.
+ *
+ * Both assertions below run at build time and both name this page in their message.
+ * `assertCapabilityCoverage` is the module contract the homepage also runs — repeated here
+ * deliberately, since either page can be built alone and each should fail on its own.
+ * `assertDetailCoverage` is this page's own: a capability with no detail renders as a
+ * heading with nothing under it, and nothing else in the repo would notice.
+ *
+ * ---------------------------------------------------------------------------------------
+ * THREE THINGS THE MARKUP SAYS THAT THE HOMEPAGE DOES NOT
+ * ---------------------------------------------------------------------------------------
+ * 1. WHERE A CAPABILITY COMES FROM. Every group states whether core supplies it or the
+ *    installed module does. The homepage carries one chip on one group; here it is a full
+ *    sentence on all five, because this is the page a reader arrives at wanting to know
+ *    what they get on a deployment with no module at all.
+ *
+ * 2. WHAT NEEDS A MODULE TO FILL IT. Teams and Team forums are core machinery that cannot
+ *    originate a Team — see the `needsModule` note in `capabilities.mjs` for what the tree
+ *    actually says. That is neither "core" nor "module-supplied", and a page that offered
+ *    only those two words would have to lie in one direction or the other (D24).
+ *
+ * 3. WHERE TO SEE IT RUNNING. Capabilities with a stable public route carry a deep link
+ *    into the demo, hidden until a `demoUrl` is mounted (D25). The markup contract is
+ *    exact and `scripts/checkBrand.mjs` enforces it:
+ *
+ *        href="" data-demo-url="" data-demo-path="/uo/market"
+ *
+ *    `applyBrand.mjs` recomputes all three attributes at boot. Do not reorder them, do not
+ *    insert anything between them, and do not write a path into the `href` — the rewrite
+ *    matches bytes, and a stock build hides every one of these links, so a mistake here is
+ *    invisible until the day somebody configures a demo.
+ */
+assertCapabilityCoverage(platform.moduleUoCapabilities);
+assertDetailCoverage();
+
+const title = 'Features';
+const description =
+  'What a Runic Gateway deployment does — core, and what the installed game module adds.';
+---
+
+<Base title={title} description={description}>
+  <PageHeader eyebrow="What you get" title="Everything the platform does">
+    <p>
+      Grouped the way the software is actually divided, because that division is the thing
+      most worth understanding before you install it: the core site is game-agnostic and does
+      not know what a shard is, and everything that does arrives as an <a href="/modules/"
+        >installable module</a
+      >.
+    </p>
+    <p>
+      Today there is one module and it covers Ultima Online, so the second group below is
+      what a UO deployment gets. On a deployment with no module, that group is simply absent
+      and the other four are unchanged.
+    </p>
+  </PageHeader>
+
+  {
+    capabilityGroups.map((group) => (
+      <section class="page section group" id={group.id}>
+        <div class="group__head">
+          <h2>{group.title}</h2>
+          <span class:list={['chip', group.moduleSupplied && 'chip--module']}>
+            {group.moduleSupplied ? 'From the installed module' : 'Core'}
+          </span>
+        </div>
+
+        <p class="prose group__summary">{group.summary}</p>
+
+        <ul class="group__items">
+          {group.items.map((item) => (
+            <li class="panel group__item">
+              <div class="group__item-head">
+                <h3>{item.label}</h3>
+                {item.needsModule && <span class="chip chip--needs">Needs a module</span>}
+              </div>
+
+              <p class="group__detail">{item.detail}</p>
+
+              {item.demoPath && (
+                <a
+                  class="demo-link"
+                  href="" data-demo-url="" data-demo-path={item.demoPath}
+                  rel="noopener noreferrer"
+                >
+                  See it running
+                </a>
+              )}
+            </li>
+          ))}
+        </ul>
+      </section>
+    ))
+  }
+
+  <NotBuilt scope="features" title="Things a reader could reasonably expect, that are not here" />
+</Base>
+
+<style>
+  .group__head {
+    display: flex;
+    flex-wrap: wrap;
+    align-items: baseline;
+    gap: 0.75rem;
+  }
+
+  .group h2 {
+    margin: 0;
+    font-size: clamp(1.5rem, 3vw, 1.95rem);
+  }
+
+  .group__summary {
+    margin: 0.85rem 0 0;
+    color: var(--muted);
+  }
+
+  .group__items {
+    display: grid;
+    gap: 1rem;
+    margin: 1.75rem 0 0;
+    padding: 0;
+    list-style: none;
+    grid-template-columns: repeat(auto-fit, minmax(min(100%, 21rem), 1fr));
+  }
+
+  .group__item {
+    display: flex;
+    flex-direction: column;
+  }
+
+  /* The chip is taller than the heading's line box, so a card that has one starts its
+     body a few pixels lower than the card beside it. Reserving the chip's height on
+     every head lines the row up whether or not the marker is there. */
+  .group__item-head {
+    display: flex;
+    flex-wrap: wrap;
+    align-items: center;
+    gap: 0.55rem;
+    min-height: 1.75rem;
+    margin-bottom: 0.6rem;
+  }
+
+  .group__item h3 {
+    margin: 0;
+    color: var(--gold);
+    font-size: 1.04rem;
+  }
+
+  .group__detail {
+    flex: 1;
+    margin: 0;
+    color: var(--muted);
+    font-size: 0.94rem;
+  }
+
+  /* The module-supplied chip takes the portal colour rather than gold: it is the same
+     distinction the data-path diagram draws in cyan on the homepage — the parts that
+     know about a game — and using one colour for one idea across the site is cheaper
+     for a reader than two decorative ones. */
+  .chip--module {
+    border-color: color-mix(in srgb, var(--portal) 45%, transparent);
+    color: var(--portal);
+  }
+
+  /* Not a warning. It says which of the two halves supplies the thing, on the two
+     capabilities where the answer is "both" — core builds it, a module fills it. */
+  .chip--needs {
+    border-color: color-mix(in srgb, var(--portal) 30%, transparent);
+    color: var(--dim);
+    font-size: 0.72rem;
+  }
+
+  /* Set as a link rather than a `.btn`: there is one of these per capability and a row
+     of buttons inside a card grid would read as the primary action of the page, which
+     it is not — the primary action is reading the list. `.demo-cta` in global.css stays
+     the button treatment, for the homepage's single slot.
+
+     It is the flex item itself rather than a paragraph wrapping one, so that
+     `global.css`'s `[data-demo-url=''] { display: none }` takes the margin away with
+     it. A wrapper would survive its hidden child and leave a 1rem gap at the foot of
+     every card in a stock build — and hiding the wrapper with `:has()` would have put a
+     second `data-demo-url` in the file, which `checkBrand.mjs` reads as a demo slot
+     written outside its contract. The check is right to: it cannot tell a selector from
+     an attribute, and it should not have to guess. */
+  .demo-link {
+    display: inline-flex;
+    align-items: center;
+    gap: 0.35rem;
+    margin-top: 1rem;
+    color: var(--portal);
+    font-size: 0.88rem;
+    text-decoration-color: color-mix(in srgb, var(--portal) 40%, transparent);
+  }
+
+  .demo-link:hover {
+    color: var(--portal-bright);
+  }
+
+  .demo-link::after {
+    content: '\2197'; /* north-east arrow: this leaves the site */
+  }
+</style>