feat(tui): add cloud sync settings screen

[mgaldamez]

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

Cloud configuration is currently CLI/env-driven and invisible to TUI users:

• Server URL: set via engram cloud config --server <url>
• Token: set via ENGRAM_CLOUD_TOKEN, with cloud.json.token as an intentional fallback
• Project enrollment: separate per-project CLI command

The TUI is the project's primary visual interface and currently has no entry point for cloud configuration.

Proposed Solution

Add a Cloud sync settings menu item to the Engram TUI dashboard with three sub-screens:

1. Cloud Config: form to set the server URL plus a read-only token status line showing the active source (ENGRAM_CLOUD_TOKEN env var, cloud.json.token fallback, or not set). The TUI persists only the server URL; the token is never written by the TUI.
2. Cloud Status: read-only view of server URL, connection health, last sync, pending mutations, and last error.
3. Project Enrollment: list of local projects with enroll / unenroll toggles.

Before saving the server URL, the TUI pings the server's health endpoint and surfaces the result (reachable / unreachable / unauthorized). A 401 still persists the URL because server reachability and auth are independent concerns.

A small docs update is bundled: docs/engram-cloud/troubleshooting.md should explicitly document the cloud.json.token fallback as intentional, with the env var taking precedence. No code change required — the runtime already behaves this way (see issue #343).

Affected Area

• TUI (screens, navigation, rendering)
• Documentation (troubleshooting.md)

Alternatives Considered

• Adding a masked token input and writing cloud.json.token from the TUI: rejected because the project philosophy keeps tokens out of disk where possible.
• Removing the cloud.json.token fallback from resolveCloudRuntimeConfig: rejected as a breaking change for users who currently rely on it.
• Implementing OAuth or browser login in the TUI: rejected — out of scope for a client-only change and would require server-side work.
• Leaving cloud setup CLI-only: rejected — the TUI is the project's visual interface and the current flow is a discoverability / UX gap.

Implementation Plan

The change will land via 4 chained PRs against a tracker branch feat/tui-cloud-config (Feature Branch Chain):

1. PR 1: TUI dashboard entry + sub-menu + docs update.
2. PR 2: Cloud Config form + ping command + save flow.
3. PR 3: Cloud Status view.
4. PR 4: Project Enrollment toggles.

Each PR follows strict TDD, adds zero new dependencies, and stays under ~400 changed lines. Tests run with go test ./....

Additional Context

• Explore analysis: engram memory topic sdd/tui-cloud-config/explore.
• Spec: engram memory topic sdd/tui-cloud-config/spec.
• Existing CLI surface: cmd/engram/cloud.go.
• Existing token resolution: cmd/engram/main.go:resolveCloudRuntimeConfig (line 447).
• Existing docs: docs/engram-cloud/troubleshooting.md.
• Prior fix: engram cloud config --status alias and ENGRAM_CLOUD_TOKEN precedence (issue fix(cloud): client v1.15.9 sync --cloud does not send Authorization header despite valid cloud.json #343).

[Alan-TheGentleman]

Removing this attachment. We do not accept patch ZIPs from unknown accounts. If you want to contribute, open a PR from a fork with source changes that can be reviewed through GitHub.

[mgaldamez]

Hi! 👋

Wanted to share the approach we're taking on this so the review goes smoothly:

How we worked

• SDD analysis (explore → proposal → spec → tasks) on mgaldamez/engram to understand the TUI patterns, the cloud config CLI, and the docs/code contradiction around the cloud.json.token fallback.
• Decision: align the docs to the code (keep the fallback as a feature, see fix(cloud): client v1.15.9 sync --cloud does not send Authorization header despite valid cloud.json #343). No change to resolveCloudRuntimeConfig or its test.
• Implementation in strict TDD: RED → GREEN → TRIANGULATE → REFACTOR. Zero new Go modules, no Co-Authored-By lines.
• Verified against the spec; addressed all per-function coverage gaps and hardened the tests against ENGRAM_CLOUD_TOKEN env-var leaks.

How we'll deliver the PRs
The change is ~1500 lines spread across 4 features + 1 test-fix, so we're using a Feature Branch Chain:

• Tracker branch feat/tui-cloud-config (draft, no-merge) targets main
• PR 1 feat/tui-cloud-config-01-nav-docs → tracker (T-01 + T-07, ~120 lines)
• PR 2 feat/tui-cloud-config-02-config → PR 1 (T-02 + T-03 + T-04, ~996 lines)
• PR 3 feat/tui-cloud-config-03-status → PR 2 (T-05, ~270 lines)
• PR 4 feat/tui-cloud-config-04-enrollment → PR 3 (T-06, ~300 lines)
• PR 5 feat/tui-cloud-config-05-fixes → PR 4 (test fixes, ~200 lines)

Each PR is one topic, reviewable in isolation. Nothing reaches main until you approve all 5 and we merge the tracker.

What we'd love from you

• status:approved on this issue (so PR Validation passes on each child PR).
• Any early feedback on the split — happy to adjust before opening.

All branches are pushed to mgaldamez/engram and ready to send over. Thanks!