Onboarding funnel events cannot be correlated into a single run

从 issue 中描述的 CLI 入口路径和 worker 启动开始，然后跟踪现有 telemetry 事件信封在每个 thread 中的创建方式。完成意味着一次启动中的每个已列出的 onboarding 和 gateway-auth 事件，在两个 telemetry 模块实例之间都携带相同的非持久化标识符；验证现有的 telemetry 流程，并在属于范围的情况下验证 machine-id 创建时的竞争条件。

Problem

Onboarding telemetry events cannot be correlated into a single user's funnel, because the events that make up one first run are emitted from two different threads at times when no common identifier exists.

altimate-code tui runs the TUI on the process main thread and the HTTP server in a worker. Each loads its own instance of the telemetry module. The first-run UI events (onboarding_started, model_picker_shown, provider_selected, the Big Pickle pair, onboarding_completed, the scan-gate pair) and the gateway auth events all fire before any chat session exists, so they stamp an empty session_id and land under the synthetic startup session. The activation events (activation_menu_shown, activation_job_selected, first_job_completed, first_prompt_sent) fire later from a real session and carry its real id.

The result: the top of the funnel and the bottom of the funnel share no key.

There is a fallback identifier — machine_id, a random UUID at ~/.altimate/machine-id — but it is unreliable for exactly this case. On a genuinely new install both threads can observe the file missing and independently create it, so a single first run can emit two different machine_id values. (That race is worth fixing regardless, and is cheap: create the file exclusively and re-read on collision.)

Impact

Countable today: impressions, choices, gateway auth outcomes, scan/skip splits, sample setup invocations — anything that is a simple tally of one event type.

Not answerable today:

• End-to-end conversion. "How many people who saw the picker ended up connected?" requires linking a model_picker_shown to an onboarding_completed.
• Per-attempt drop-off. onboarding_abandoned carries a last_stage, but it cannot be tied to the events that led there.
• Retry behaviour. A user who fails gateway auth and succeeds on the second attempt is indistinguishable from two users.
• time_to_connect_ms attribution when a user retries.

In other words: the events are individually correct, but the funnel is not reconstructable, which is the main thing the taxonomy exists for.

Proposal

Generate one random id per process launch and stamp it on every onboarding event, from both threads.

• Generated once in the CLI entry path, before either thread emits.
• Passed to the worker at startup so both telemetry module instances use the same value.
• Not persisted, not derived from anything about the machine or user, and not reused across launches. It carries no identifying information — it exists only to group events that belong to the same run.

A launch is the right grain here: onboarding state already resets on every process start by design, so "one launch" and "one onboarding attempt" are the same thing in practice.

Alternatives considered

• Reuse machine_id. Groups a machine, not an attempt, so retries and repeat launches collapse together. Also affected by the creation race above.
• Reuse session_id. Does not exist for most of the funnel, which is the original problem.
• Fix attribution after the fact by joining on timestamp proximity. Fragile, and impossible to do correctly for concurrent instances on the same machine.

Notes

This does not require a new sink, endpoint, or storage. It is one value threaded through the existing event envelope.