feat(connectors): emit `connector.activation.changed` for CLI/SDK activation writes

[alexey-tyurin]

Quick check

• I've searched existing issues and didn't find a duplicate.
• This relates to Gaia Agent UI (gaia chat --ui).
• This relates to the SDK, CLI, or a specific agent.

What problem are you trying to solve?

Activation toggles only push live UI updates when they go through the HTTP router. The connector.activation.changed SSE event is emitted from the PUT/DELETE handlers in src/gaia/ui/routers/connectors.py, but gaia connectors activate / deactivate (CLI) and direct SDK calls write the same ~/.gaia/activations.json ledger silently.

Result: with the Agent UI Settings tab open, a CLI-driven activation change is invisible until the user navigates away and back to force a refetch. That makes CLI ↔ UI workflows confusing — the activation actually took effect, but the panel keeps lying about state. This was called out as a follow-up on PR #1219 (closes #1005).

Proposed solution

Two viable options:

1. Route CLI/SDK writes through the router layer — share a single internal entry point (e.g. activations.set(...) / activations.delete(...)) that always emits the SSE event after a successful write, regardless of caller. Cleanest, mirrors how PR feat(connectors): per-agent MCP tool-visibility activations (#1005) #1219 centralized the MCP-only guard at connectors/api.py.
2. File-watcher on ~/.gaia/activations.json — the FastAPI server tails the ledger and emits connector.activation.changed whenever the file mtime moves. Looser coupling, also covers third-party writes.

Option 1 is preferred — it keeps the event source authoritative and avoids the watcher race when multiple processes write the ledger concurrently (already serialized by the per-process lock from #1219).

Acceptance criteria

• gaia connectors activate <id> --agent <agent_id> triggers a connector.activation.changed SSE event with the same payload the HTTP PUT handler emits
• gaia connectors deactivate ... triggers the same event with active: false
• With Agent UI Settings open, a CLI activation toggle updates the "Active for" state without requiring a navigation refresh
• Unit test covers the CLI → SSE path (mock the event bus, assert publish was called)

[github-actions]

Confirmed — gaia.connectors.api.activate() / deactivate() write the ledger without touching the emitter, so any caller outside the FastAPI process is invisible to subscribed UIs. Worth flagging one nuance before locking in the design.

🟡 Option 1 alone doesn't cover the CLI case. The events module is explicit about this in src/gaia/connectors/events.py:6-9: the SSE emitter is registered by the running FastAPI router via set_emitter at app startup; the CLI runs as a separate process and falls through to the no-op _LoggingEmitter. Moving the emit() calls into src/gaia/connectors/api.py:319 and api.py:341 fixes in-process SDK callers (e.g. an agent that imports api.activate while the UI server is hosting it), but gaia connectors activate in its own shell won't reach the SSE queues. That's the case the issue actually describes.

Suggested shape — hybrid:

1. Centralize emit in api.activate / api.deactivate (Option 1) so the in-process path is authoritative and the HTTP handlers at src/gaia/ui/routers/connectors.py:805-808 / :831-834 stop duplicating it. Clean, mirrors PR feat(connectors): per-agent MCP tool-visibility activations (#1005) #1219.
2. Add a watcher on ~/.gaia/activations.json in the FastAPI server lifespan (Option 2) using the existing gaia.utils.FileWatcher. On mtime change, diff against the last-known ledger snapshot and re-emit connector.activation.changed per delta. This covers the CLI process and any third-party writer; the per-process lock from feat(connectors): per-agent MCP tool-visibility activations (#1005) #1219 keeps the watcher race-free.

That keeps the event source authoritative for the SDK path and recovers the cross-process signal for CLI without coupling the CLI to the server.

🟢 Test plan addition: alongside the unit test the issue proposes, an integration test that launches gaia ui in a subprocess, subscribes to /api/connectors/events, then runs gaia connectors activate in another subprocess and asserts the event arrives within a small window would actually prove the CLI → UI loop closes.

If hybrid is more scope than wanted right now, fine to land Option 1 first and track the cross-process piece as a follow-up — but the acceptance criterion "with Agent UI Settings open, a CLI activation toggle updates ... without requiring a navigation refresh" won't hold without the watcher (or some equivalent IPC).

@kovtcharov-amd — flagging this for direction on whether to scope Option 1 + watcher together or split.

[alexey-tyurin]

@itomek I will work on this issue.

[alexey-tyurin]

Hi @itomek - my PR #1309 for this issue got "All check have passed" and Verdict Approve from github-actions.