feat: start the daemon after a successful setup

[vreshch]

What changed

After agentage setup completes a sign-in, the daemon is now started so account sync begins immediately and the next agentage status shows daemon/mcp/sync as healthy. Previously setup signed in but left the daemon stopped (it only autostarted lazily on the first memory verb).

The success path (src/commands/auth/setup.ts, after credentials are saved) calls the same ensureDaemon() the memory verbs use, via a new startDaemon helper and a mockable ensureDaemon dep on SetupDeps. ensureDaemon is idempotent: it reuses a live daemon (no restart) and starts a stopped one (detached), returning a client or null. Version-mismatch handling is unchanged (it already lives inside ensureDaemon).

Output lines match the existing no-emoji tone:

• daemon started or reused -> Daemon running.
• spawn failed -> Could not start the daemon - run: agentage daemon start
• disabled -> Daemon disabled - account sync will run in-process on demand.

Disable-switch behavior

• --no-daemon / AGENTAGE_NO_DAEMON=1 (daemonDisabled()): short-circuits, does NOT start the daemon, prints the one-line disabled note.
• --disconnect (sign-out): returns before the sign-in flow, never reaches startDaemon.
• Only the successful sign-in path starts the daemon. --no-browser still reaches it (it is a normal sign-in).

Test coverage

New unit tests beside setup.ts:

• success path calls ensureDaemon exactly once
• --disconnect does NOT call ensureDaemon
• AGENTAGE_NO_DAEMON=1 short-circuits (no ensureDaemon call) while auth is still persisted

npm run verify green (type-check + e2e type-check + lint + prettier + 442 tests + build).

Smoke (isolated AGENTAGE_CONFIG_DIR): node dist/cli.js setup --disconnect -> "Nothing to disconnect." (no daemon touched); node dist/cli.js --no-daemon status -> clean. A real OAuth sign-in cannot be driven headless, so the daemon-start line is unit-verified (mocked ensureDaemon) and needs a real login to confirm end-to-end.

Observation (not implemented) - status auth line shows UTC absolute expiry

The status auth line renders token valid until <ISO-Z> in UTC. For a user in CEST near midnight this reads as "yesterday" even when the token is valid ~1h into the future (UTC-vs-local confusion).

Findings:

• The expiry shown is accessTokenExpiresAt from the OAuth introspection endpoint (/api/auth/mcp/get-session), surfaced via introspectToken -> report.auth.tokenExpiresAt -> authLine in status.ts. It is the ACCESS-token expiry, not the session lifetime.
• Access tokens are short-lived. Fresh-login TTL in the token exchange is expires_in seconds (see toAuthState); the CLI refreshes proactively when past expiry. Practically this is a short window (roughly minutes-to-an-hour class), which makes an absolute timestamp both noisy and easy to misread. status.ts already downgrades a past/unrefreshable expiry to (session active).

Proposed display (owner to pick, not implemented here):

1. Relative: signed in (token expires in 47m) - clearest, no timezone ambiguity, honest about the short TTL.
2. Local time: signed in (token valid until 01:12 local) - fixes the UTC confusion but still exposes a short-lived, noisy absolute time.
3. Drop the token time entirely: signed in (session active) - introspection already proves the session is live server-side; the access-token expiry is an implementation detail the user rarely needs.

Recommendation: option 3 (or option 1 if a countdown is desired). The access token is refreshed automatically, so its exact expiry is low-value to surface; showing it invites the "why does it say yesterday" confusion for little benefit.

[github-actions]

🎉 PR Validation ✅ PASSED

Commit: f1f595f3dbab30ef299538ad2fb487b92cb93ffc
Branch: feature/setup-starts-daemon

Checks:

• ✅ Release guard (no version/changelog changes)
• ✅ Dependencies installed
• ✅ Type check passed
• ✅ Linting passed
• ✅ Format check passed
• ✅ Tests + coverage passed
• ✅ Build successful

Ready to merge! ✨

---

🔗 View workflow run
⏰ Generated at: 2026-07-08T22:45:24.847Z