ci_trigger: Improve deploy monitoring UX

[krisrowe]

Context

gapp_ci_trigger currently dispatches a GitHub Actions workflow and by default blocks (watch=True) until completion, polling the run status. This works but has UX concerns:

• Blocks the caller for several minutes during a deploy
• The polling is opaque — no streaming progress updates
• If the caller doesn't want to wait, watch=False returns a run URL but no way to check status later without leaving the tool

Options to consider

1. Fire-and-forget with status tool (recommended)

ci_trigger dispatches and immediately returns the run ID and URL. A separate ci_run_status tool (or extending ci_status) lets the caller check progress on demand. Benefits:

• Non-blocking — caller can do other work
• Status is checkable anytime
• Simple implementation

2. SSE/streaming progress

Use MCP's streaming capabilities to push status updates as the deploy progresses. More responsive but adds complexity — the MCP server would need to poll GitHub and stream events.

3. Keep blocking but improve feedback

Keep watch=True as default but provide better progress output (current step, elapsed time). Least disruptive change.

4. Hybrid

Default to fire-and-forget, offer watch=True as opt-in for callers that want to block.

Recommendation

Option 4 (hybrid) — change the default to watch=False so ci_trigger is fast, and add a ci_run_status tool for checking progress. Keep watch=True available for scripts or callers that need synchronous behavior. This matches how gh workflow run works (fire-and-forget) vs gh run watch (explicit monitoring).

Current behavior for reference

gapp_ci_trigger(solution="name", watch=True)  # blocks until complete
gapp_ci_trigger(solution="name", watch=False) # returns immediately with run URL