Instrument app startup cost (boot-timing marks / profiling) so splash decisions are data-driven

## Problem

The #14003 splash/startup debate (forced splash min-duration vs. fast boot) had **no data** on what app startup actually costs. Decisions were made on feel. We should be able to answer "how long does boot take, and where does the time go?" from telemetry rather than vibes.

## What already exists (audited on `origin/main`)

- Sentry is configured with **`tracesSampleRate: isCloud ? 1.0 : 0`** in `src/main.ts` — so cloud gets transaction/page-load tracing, but desktop and self-hosted web get **`0`** (no perf data).
- There is **no profiling** anywhere: no `@sentry/profiling`, no `profilesSampleRate`, no `BrowserProfilingIntegration`.
- There are **no explicit boot-timing marks** (`performance.mark`/`measure`) around the bootstrap → `refreshRemoteConfig` → `Sentry.init` → `app.mount` → first-mount sequence.
- So even on cloud, transaction tracing gives coarse page-load timing but **not** a breakdown of the app-boot phases that the #14003 discussion actually cared about.

## Proposal (scoped — prefer the lightweight option)

**Preferred (lightweight, all distributions):** add a small set of `performance.mark()` / `performance.measure()` marks around the boot phases (module-eval start, remote-config resolved, Sentry ready, app mounted, splash removed) and emit the measures as a Sentry span/measurement (and/or Datadog RUM custom timing on cloud). This quantifies startup cost everywhere at negligible cost and directly informs splash min-duration decisions.

**Optional (heavier, cloud only):** enable Sentry browser profiling (`@sentry/profiling` + `profilesSampleRate`) for cloud sessions if a flame-graph-level breakdown is wanted. Note this adds bundle + runtime overhead — only pursue if the lightweight marks prove insufficient.

## Acceptance criteria

- [ ] Boot phase durations (at minimum: total time-to-mount and time-to-splash-removed) are captured and visible in telemetry.
- [ ] Data is available on cloud at a minimum; lightweight marks also work on desktop/web.
- [ ] A concrete startup-cost number can be pulled to settle the #14003 splash min-duration question.
- [ ] No meaningful startup regression introduced by the instrumentation itself.

## Motivating incident

The #14003 splash vs. fast-boot debate, which had no startup-cost data to reason from.

Start in src/main.ts and trace the startup sequence from remote-config resolution through Sentry initialization and app.mount; then locate where the splash is removed. Compare the existing telemetry setup with the acceptance criteria, and determine how to capture and expose total time-to-mount and time-to-splash-removed without meaningful startup regression. Done means those durations are visible in telemetry, including on cloud.

Written by the indexing model from the issue text.