docs(recipes): add deploy versioning boundary

Document deployment and version compatibility for hemx apps: release unit, runtime asset caching, rolling deploy policy, fingerprint mismatch behavior, semver buckets, upgrade notes, and deployment checks without adding platform code to core.

req: abi/001

req: abi/002

req: abi/003

req: abi/004

req: abi/005

req: runtime/004

req: failure/005

README.md

@@ -85,7 +85,7 @@ and integrate at explicit boundaries. req: laws/002 req: auth/001
   fields and credentials semantics. See `docs/recipes/auth-session-csrf.md`. req: auth/004 req: auth/005
 - **Observability, feature flags, killswitches, deploy:** use explicit platform
   integrations around handlers, routes, and runtime assets. Core hemx must not
-  vendor providers or add framework-specific magic.
+  vendor providers or add framework-specific magic. See `docs/recipes/deploy-versioning.md`.
 - **PWA/offline/sync:** optional adapters may reuse generated targets/effects,
   but core hemx must not gain a mandatory client state graph or local app
   runtime. req: canonical_authoring/008
@@ -104,7 +104,7 @@ The generated API, symbols, effect wire schema, and JavaScript runtime carry
 schema/ABI versions. Deploy a matching server, generated output, and runtime
 asset together. Build fingerprints are derived from the generated surface and ABI
 parts; the runtime refuses incompatible effect responses and integrations should
-fall back to a full page reload when possible. req: abi/001 req: abi/002 req: failure/005
+fall back to a full page reload when possible. See `docs/recipes/deploy-versioning.md`. req: abi/001 req: abi/002 req: failure/005
 
 Before a v1 release, the semver policy and upgrade notes should explicitly state
 which surfaces are stable: beginner generated helpers and handler shapes; the