docs: explain reusable partials

Add the public 'Where are my components?' answer: hemx maps framework component jobs to hemplate partials, generated helpers, app-owned state, IntoEffect composition, and explicit leaf islands. The pre-commit guard now only blocks commits that change REQUIREMENTS.md without an AGENTS.md review, so unrelated follow-up commits are not trapped by old history.

req: canonical_authoring/002

req: canonical_authoring/003

AGENTS.md

@@ -54,6 +54,7 @@ Keep it stable. Prefer pointers to canonical sources over copied structure, file
 - hemx core stays small: effects, typed ids, registries, and wire schema only.
 - Routing, auth, sessions, transport, transitions, sync, and storage belong in integration/user crates.
 - Public examples and beginner APIs should use generated resources and `IntoEffect`, not raw ids or runtime opcodes.
+- The public component-reuse explanation lives in `docs/recipes/reusable-partials.md`; do not grow a client component framework to explain partial composition.
 - Hemlate examples must use real hemplate syntax, not Vue/Handlebars sketches: `{+ expr +}` for escaped text, `{+= expr =+}` only for trusted/rendered HTML, `+attr="expr"` for dynamic attributes, and Rust-shaped `h-if`, `h-for`, `h-match`, `h-case` directives (`h-case="_"` is the default arm).
 - JS runtime changes must preserve root-scoped lookup and avoid selectors, VDOM, expressions, and per-node listeners.
 - Host capability adapters must stay at the `hemx-host` boundary: they may call host APIs and return host events, but they must not mutate DOM or own app/domain state. req: host/002