Add telemetry for railway ca launches, lifecycle ops, and setup

[codyde]

Summary

railway ca had essentially no bespoke telemetry. The only signal was the generic per-dispatch event the commands! macro fires for every top-level command (command="cloud_agent", sub_command in {None, "setup", "start"}, success = the top-level Result).

That's close to useless for the most common path: bare railway ca runs a TUI event loop that swallows internal errors (SSH attach failures, credential-mint failures, launch failures) into toast text and keeps looping, so command() almost never returns Err — every bare railway ca invocation reported success: true regardless of what actually happened. There was also no visibility into which agent got launched, whether a VM was created vs. reused, agent lifecycle actions (sleep/wake/delete), session reattach/kill, or setup/wizard choices.

This adds a small commands/cloud_agent/telemetry.rs module and wires it in at the natural convergence points, following the CLI's existing conventions (additive CliTrackEvent detail events, same shape as the per-tool MCP and per-stage SSH events in commands/ssh/tel.rs and commands/service.rs's track_service_source). No new GraphQL mutations — everything reuses the existing cliEventTrack event, already gated by DO_NOT_TRACK / RAILWAY_NO_TELEMETRY / the local telemetry preference.

• Launch outcome (cloud_agent_launch): harness, created-vs-reused, real duration, fired from inside code::prepare() itself — so it fires for railway code, railway ca start, and the TUI's start_launch alike, and survives the TUI catching the error afterward.
• Agent lifecycle ops: sleep/wake/delete from the manage screen.
• Session events: reattach (connect + open), kill, opening a freshly prepared session, and the auto-sleep-on-quit whose result was previously discarded with let _ = (a failure there means an agent is left running and billing compute unattended).
• Setup/wizard: one flat event per choice (agent/theme/project/skills) on save, from both railway ca setup and the TUI's first-run wizard.

No user-visible behavior changes; no free text is ever logged (no prompts, no session/agent/project names — only IDs, fixed slugs, and truncated error messages).

Test plan

• cargo build
• cargo fmt
• cargo clippy --all-targets — no new warnings in changed files
• cargo test --bin railway — 945 passed; the 3 auth_sim failures are pre-existing on master too, unrelated to this change
• Manual smoke test against a real account (launch, reattach, sleep/wake/delete, quit with a session open, ca setup) to confirm events post with the expected command/sub_command/success

[codyde]

Ran an adversarial code review against this diff and it surfaced real bugs, now fixed in a follow-up commit:

1. Truncation panic (high severity): String::truncate(256)/s[..256] on an error message panics whenever byte 256 lands mid-character — any error with a non-ASCII byte near the boundary (an accented/CJK/emoji character in a path, a non-English GraphQL error). This crate builds with panic = "abort", so that panic takes down the whole CLI process, not just the log call. The same pattern existed independently in five places, including two I didn't touch (macros.rs's generic per-command event — fired for literally every command — and the MCP tool event). Added one shared crate::telemetry::truncate_message (char-boundary-safe) and pointed all five call sites at it, with a regression test reproducing the panic on the old logic.

2. TUI-blocking regression: I'd made handle_message/open_session async so their telemetry could be awaited inline instead of spawned, to close a race where a fire-and-forget tokio::spawn might not flush before the process exits on quit. That "fix" was worse than the bug: it makes the whole interactive TUI block on a live network call on ordinary actions (killing a session, a failed reattach) — up to the telemetry timeout, and up to ~4x that for setup's four sequential events. Reverted to fire-and-forget tokio::spawn for these, consistent with every other background task already in this file (session prefetch, sweep, refresh) — none of them get joined either. A rare, silent loss of one event on an immediate quit is a much smaller cost than a guaranteed multi-second freeze on everyday use.

3. Silent gap: resolve_agent_choice() failures (conflicting --codex --claude, no default agent configured non-interactively) returned before the launch timer/tracking even started, so a real, user-hit failure mode was invisible to cloud_agent_launch entirely instead of showing up as a failure. Now tracked under harness "unresolved".

4. Doc accuracy: the new module's comment overclaimed "nothing here logs free text." error_message carries the same truncated {err:#} text every other failure event in this CLI already sends, which can include a user-typed identifier (e.g., an unknown environment name) when the underlying error formats one in — consistent with existing codebase-wide behavior, not a new leak, but the comment now says so accurately instead of overpromising.

cargo test --bin railway: 948 passed (up from 945 — added truncation regression tests), same 3 pre-existing auth_sim failures unrelated to this change. No clippy warnings in any touched file.