feat(cloud): support per-project cloud server routing

[JuanJ27]

Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

Problem Description

Engram currently assumes a single cloud server configuration for all projects on the same local installation.

This becomes limiting when a user needs to keep projects isolated across different cloud environments or trust boundaries. For example, one local installation may contain:

• project-a synced to https://cloud-a.example.test
• project-b synced to https://cloud-b.example.test

Today, the cloud target is configured globally, which makes this kind of separation difficult or impossible without changing configuration between runs or maintaining separate local environments.

Proposed Solution

Add support for resolving the cloud server by project instead of relying only on a single global server setting.

One possible approach:

• keep the current global cloud server as the default
• allow optional per-project overrides
• resolve the effective cloud target at runtime using the current project

Example behavior:

engram cloud config --server https://default-cloud.example.test
engram cloud config --project project-a --server https://cloud-a.example.test
engram cloud config --project project-b --server https://cloud-b.example.test

Expected outcome:

• projects without overrides continue using the global default
• projects with overrides use their assigned server
• sync/enroll/status commands consistently resolve the same target for that project

This would help with project-level isolation while preserving backward compatibility for existing single-server users.

Affected Area

CLI (commands, flags)

Alternatives Considered

• Running separate local Engram environments per trust boundary
• Rewriting the global cloud config before each sync
• Treating this only as an authentication problem

These workarounds are operationally heavier and do not fully address project-level routing as a first-class client behavior.

Additional Context

This request is intentionally framed as client-side cloud target routing and project isolation.

It may touch config loading, runtime target resolution, and cloud-related command behavior. Backward compatibility is important:

• existing users with a single configured cloud server should not need to migrate immediately
• per-project routing should be additive

[JuanJ27]

Additional related case:

While investigating per-project cloud routing, I found another behavior that seems to come from the same global-sync assumption.

Autosync can enter a degraded state with:

reason_code: non_enrolled_pending_mutations

even when the user only intends to sync a subset of enrolled projects.

The current behavior appears to be:

• pending mutations for enrolled projects are eligible for cloud sync
• pending mutations for non-enrolled projects are not uploaded
• however, the presence of pending mutations from non-enrolled projects can still degrade the autosync manager

This is related to this feature request because per-project server routing should probably also define per-project sync scope and failure isolation.

Expected direction:

• a project with a configured route and enrollment should sync independently
• a project outside the active cloud scope should not degrade healthy project routes
• route/config/enrollment failures should be reported for the affected project, not globally when possible
• if cleanup tooling is needed for old pending non-enrolled mutations, it should be explicit, dry-run first, and should not delete memory data

This does not change the core proposal, but it adds an important autosync design constraint: multi-project cloud sync should avoid one global pending queue or one global degraded state blocking otherwise healthy project routes.

[Alan-TheGentleman]

Valid pain point for multi-trust deployments, but per-project cloud routing touches config loading, runtime resolution, autosync scope, and failure isolation. Before a PR, propose the contract: how is the per-project target configured and resolved, and how do failures isolate per project? Design-gated, not rejected. Align here first.