bug: startup_ready.fresh_install is always false for headless serve/run first runs

Found during the v0.11.1 release review (Tech Lead persona). Deferred because: decoupling fresh-install detection from the TUI welcome flow is more than a quick fix.

`startup_ready.fresh_install` is set only when `track()` observes a non-upgrade `first_launch` event (`packages/opencode/src/altimate/telemetry/index.ts`), and `first_launch` is only tracked from `packages/opencode/src/cli/welcome.ts`, which is TUI-only onboarding. `serve` and `run` never go through it, so a brand-new machine's first `altimate serve` or `altimate run` always reports `fresh_install: false`.

Those are exactly the entry points the v0.11.0 first-run freeze hit, and the "startup time by command, fresh vs returning" KQL in `docs/internal/first-run-telemetry.md` will mis-bucket every fresh headless install.

**Suggested fix.** Derive `fresh_install` from the install marker / machine-id probe directly (the same signal `first_launch` uses), independent of which command consumed it, or emit `first_launch` from the CLI middleware for every command.