docs: bound hemx mobile fit

Name when the mobile starter is the right suckless path and when to use an explicit native shell or island instead of pretending hemx is a general native UI framework.

req: ceremony/006

req: host/002

docs/recipes/mobile-release.md

@@ -18,6 +18,22 @@ The created app includes the same `hemx-workout mobile-release` and
 `hemx-workout mobile-verify` commands, plus `MOBILE_STARTER.md` naming the host,
 recovery, and release-kit boundary. req: ceremony/006
 
+## When to use this path
+
+Use hemx mobile when the app is still a Rust-owned hypermedia product: forms,
+lists, keyed partial updates, server-verified actions, installability, offline or
+host recovery from app-owned command/event/projection truth, and a few explicit
+host capabilities such as share, haptics, clipboard, notifications, or file
+picking. The payoff is fewer moving parts: no client component runtime, no native
+UI abstraction, no plugin marketplace, and no hidden mobile state graph. req:
+ceremony/006 req: examples/006
+
+Do not use hemx mobile as a replacement for apps whose product center is heavy
+native UI, games, deep OS integration, camera-heavy capture/editing, complex
+native navigation stacks, background services, or complex multi-device offline
+sync. For those, keep hemx as a server/API surface or use an explicit native
+shell/island where the browser should not own the interaction. req: host/002
+
 For the in-repository exemplar:
 
 ```sh