Hyperpush deploy topology: split marketing site from operator app routing and product runtime boundaries

[snowdamiz]

Parent issue

• Hyperpush deployment: define frontend plus meshable backend topology #49

Outcome

Define the concrete runtime boundary between the marketing site and the real operator app.

Current state

Current reconciliation evidence does not show this product row as already shipped, so it should stay open until implementation proof exists; repo/surface wording should also normalize to the canonical public hyperpush ownership truth. Public issue wording should refer to hyperpush-org/hyperpush; local hyperpush-mono compatibility paths remain supporting workspace context only.

Acceptance criteria

• Marketing vs app hostnames/routes are explicit
• Frontend and backend runtime responsibilities are explicit
• The topology is concrete enough to implement in Docker on a generic VM
• The wording stays aligned with the current repo/code truth instead of relying on stale cross-repo or local-path assumptions.

Tracker context

• Public repo: hyperpush-org/hyperpush
• Workspace compatibility path: mesher -> ../hyperpush-mono/mesher