refactor(marketing-pages)!: delete marketing-pages demo feature

Veect retrofit (ADR-027): fourth slice of the demo-content removal.
Deletes packages/marketing-pages whole and prunes every composition
edge in one commit: core-api router mount + dep, core-cms
collection/global composition + dep + regenerated Payload types,
web-next bindAll (prod + dev-seed) + tests + about page + Tailwind
source + transpilePackages + dep, cms/core-cms payload config test
assertions, marketing-page e2e spec, tsconfig paths, fallow ignore
entry, anchor-guard + generator e2e feature lists, compliance
data-map + retention-policy regeneration, lockfile prune, and
feature-list doc entries (CLAUDE.md, AGENTS.md, glossary, app/feature
AGENTS.md).

Event teardown: marketing-pages was the sole consumer of
auth.user.signed-up (welcome-email handler + job). The handler, its
Payload tasks, and the bus subscription all lived inside the package's
own binders, so they die with it — no other package wires the
subscription. Auth's manifest `publishes` stays untouched: a publisher
with zero consumers is legal (pnpm conformance only fails on orphan
consumers, verified green). The app-level sign-up-welcome-email test
asserted the marketing-pages mailer stays empty without a bus; it is
deleted with the feature, and the now-unused test-only bind-state
helpers in web-next bind-production.ts go with it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK

docs/glossary.md

@@ -22,7 +22,7 @@ _Avoid:_ module, library, app (unless specifically `apps/`).
 The boundary classification on a package (`app`, `core`, `core-composition`, `feature`, `tooling`). Enforced by ESLint (`eslint-plugin-boundaries`) and Turborepo `boundaries`. See `AGENTS.md` → Boundary Rules.
 
 **Feature** (a.k.a. **feature package**):
-A vertical slice owning its Clean Architecture layers + integrations under `packages/<name>/`. Currently: `auth`, `marketing-pages`, `navigation`. **In architecture-refactor conversations (the `improve-codebase-architecture` skill), "module" defaults to "feature" — they're the same unit at the highest level of granularity.**
+A vertical slice owning its Clean Architecture layers + integrations under `packages/<name>/`. Currently: `auth`, `navigation`. **In architecture-refactor conversations (the `improve-codebase-architecture` skill), "module" defaults to "feature" — they're the same unit at the highest level of granularity.**
 _Avoid:_ domain, vertical (use "feature" or "vertical feature"). "Module" is acceptable inside the refactor skill specifically, where it abstractly covers "anything with interface + implementation" at any scale (use case, controller, repository port, or full feature).
 
 **Must-have core**:
@@ -190,7 +190,7 @@ The commit-message spec mandated by this template — `<type>(<scope>): <imperat
 The Google-maintained automation that reads Conventional Commits, derives semver bumps, and opens a rolling release PR with version bumps + per-package CHANGELOG entries on every push to main. Configured in `release-please-config.json` + `.release-please-manifest.json`. ADR-021.
 
 **Hybrid versioning**:
-The template's versioning strategy (ADR-021) — root template (`template-vertical`) + 3 feature packages (`@repo/{auth,marketing-pages,navigation}`) version independently from `0.1.0`. Core packages, tooling, and apps are NOT versioned (cascade-effect would invalidate the signal).
+The template's versioning strategy (ADR-021) — root template (`template-vertical`) + 2 feature packages (`@repo/{auth,navigation}`) version independently from `0.1.0`. Core packages, tooling, and apps are NOT versioned (cascade-effect would invalidate the signal).
 
 **Tag prefix**:
 The per-package prefix release-please uses to avoid tag collisions in a monorepo — `template-v0.1.0` for the root, `auth-v0.1.0` / etc. for features.