docs(arch): §22c AgentKeys app surface (CLI + web UI + daemon)

[hanwencheng]

Summary

Adds a new §22c to docs/arch.md documenting the operator-facing AgentKeys app surface — CLI + web UI + daemon as one distribution, in the agentmemory shape iam.md §2.3 points at. Pure docs PR. No code changes.

Companion to the #110 issue comment synthesizing agentmemory's architecture into a phased M1→M4 web UI roadmap.

What §22c covers

• 22c.1 — Three surfaces (CLI + web UI + MCP server) on one shared daemon, one binary distribution
• 22c.2 — Four backend kinds (hosted LLM / local LLM / task agent / chat agent) wiring the per-runtime trust path
• 22c.3 — Multi-device master pairing UX (the layer on top of §10.3.1's cryptographic flow — phone + desktop as masters)
• 22c.4 — Vendor device pairing flow (xiaozhi MagicLick, Doubao, etc.) — closes the no-auth gap from Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107's stage-1 demo
• 22c.5 — Explicit boundary: daemon stays the local trust core, does NOT become the agent runtime; web UI is the operator's view into the trust plane, NOT a trust plane itself
• 22c.6 — Cross-references to Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110 / Phase 3: LLM-host hook integration (Claude Code, Codex/ChatGPT, etc.) #133 / M6: Release management + agentkeys CLI distribution #134 + iam.md §4.4

Contradictions found + fixed in the same change

1. §9 cold-start step 9 said "Daemon: persist J1_agent; enter MCP-stdio loop + sidecar proxy" — written before Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107 made the MCP server its own surface. Now references §22c.1 for the surface separation; daemon hands off LLM-host integration via backend variant at startup.

2. §22c.1's own stale cross-ref to "§22.Backend pluggable axis" — §22's six axes don't list MCP backend. Reworded inline to describe the backend choice (DaemonBackend / HttpBackend / InMemoryBackend) explicitly, without claiming a row in §22's table.

Why now

• Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107 (Phase 1 MCP server) merged and exposed that arch.md had no canonical home for the broader app surface
• Phase 1: Parent-control web UI (mobile-responsive) for v0 demo #110 was scoped to just the parent dashboard; the research from agentmemory + the Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107 PR thread surfaced that this is the first slice of a CLI + web + daemon app distribution, not a one-off
• Locking the §22c language now means M2 vendor onboarding, M3 multi-master pairing, M4 backend wiring all have a canonical reference in arch.md to point at (rather than diverging stories per issue)

Test plan

• arch.md TOC still threads §22 → §22a → §22b → §22c → §23 in order
• All cross-refs in §22c.6 point at real anchors / real issues / real iam.md sections
• No contradictions remain with §9, §10.3, §12, §22 (verified by grep)
• Pure markdown change; no code / test impact

Anchors to verify locally:
```bash
grep -n '^## 22c\|^## 22b\|^## 23' docs/arch.md

Expect: 22b. → 22c. → 23. in order

```

🤖 Generated with Claude Code