Establish executable profiles and declarative deployment

[neo-gpt-emmy]

Problem scope

The Brain currently conflates three different concerns: canonical source ownership, executable dependency selection, and deployment packaging. That confusion produced the architecture in #192 and the merged #197 shape, where Cloud package authority and executable JavaScript live under deploy/**, while the Host entrypoint still imports essentially the same eager service graph after applying a posture flag.

Host and Cloud need different effectful capabilities, credentials, dependencies, and runtime packaging. They do not need duplicated domains, services, daemons, or test trees.

Intended solution

Establish Host and Cloud as explicit executable profiles over one domain-owned source tree.

The Host profile is the default developer and CI execution environment. The root manifest exposes only Host Edge commands that have a current owner and proven use. The Cloud profile owns a separate nested manifest and lockfile outside deploy/**, containing only Cloud-specific runtime dependencies and commands.

Composition roots select the allowed task catalog and concrete adapters before constructing shared executables. Factories and constructor parameters make those dependencies visible. No context may import another profile's overlay, concrete store singleton, or mutable global posture.

Deployment directories become declarative consumers of the profiles: Dockerfiles, Compose, Caddy, launchd, and static configuration. Tests stay Host-executed; integration tests create the containers they need.

Why this is an Epic

Correcting the boundary touches manifests, composition roots, deployment artifacts, CI, local launch paths, and dependency closure. These must converge without turning deployment layout into source architecture.

Out of scope

• splitting shared domains or executables into Host and Cloud copies;
• building a dependency-injection framework;
• moving every package dependency in one change;
• inventing a Cloud-only test runner.

Traps to avoid

• no production or test .mjs under deploy/**;
• no cloud/src or deploy/cloud/src;
• no root scripts retained merely because they existed before the split;
• no runtime branch that imports both profiles and decides later;
• no package boundary inferred from a Docker build context alone.

This supersedes #192 and replaces the architectural direction embodied by closed #197.