chore(template): clean-slate template snapshot from bb4a0c7

Curated, product-agnostic snapshot of the post-story-04 tree: demo
content deleted, auth-only reference feature, web-next shell, all gates
green. Product-specific docs, ADRs 027-029, PRDs/epics/archive, editor
library traces, and product naming are curated out; generic template
repairs (coverage provider devDeps, root test:coverage script, live
lint fixes, root-only release-please) are kept. See TEMPLATE.md for
provenance, curation list, and usage.

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

docs/decisions/adr-004-dual-mode-client.md

@@ -0,0 +1,22 @@
+# ADR-004: Dual-Mode Payload Client (Local + HTTP)
+
+## Status: Accepted
+
+## Context
+
+Apps need to access Payload CMS data. Payload 3.x offers both Local API (direct) and REST API (HTTP).
+
+## Decision
+
+`@repo/cms-client` supports both modes via `createPayloadClient()`.
+
+## Rationale
+
+- **Local mode (primary):** Direct Payload instance access — no HTTP overhead, full query capabilities (where, sort, limit, depth, page, populate). All server-side apps use this.
+- **HTTP mode (fallback):** REST API for external consumers without access to a Payload process.
+- Payload instance is injected at app startup, not imported — keeps cms-client standalone.
+- Both modes share the same `PayloadClient` interface — consumers don't know which mode is active.
+
+## Status: Superseded by ADR-007 (2026-05-04)
+
+The dual-mode client wrapper was deleted. Feature payload-backed repositories now call `getPayload({ config })` directly with the assembled config injected via constructor. See ADR-007 for rationale.