Performance dashboard: Nightly CI metrics for FlyBot smoothness #357

Why

#356 asks volunteers to measure smoothness once. That is not enough: we need a daily performance board fed by Nightly CI, so regressions show up every morning instead of after a bad release. Ties to #351 (daily tags) and the metrics chosen from #356.

Goal

A FlyBot-specific performance dashboard, updated every night from CI, showing trend lines for a fixed set of scenarios on a known machine profile.

Scope

Nightly CI suite

• Runs on a schedule (proposed: Asia/Shanghai night) on a fixed runner label/image so numbers are comparable day to day.
• Scenarios (start from Performance baseline: measure current smoothness (help wanted) #356; refine after the first baseline):
  1. Cold start to first message sendable.
  2. First-message latency (mock or fast model, so FlyBot overhead is separated from model time).
  3. Long-session scroll / open time (500+ messages fixture).
  4. Background-tab recover (cf. Timeline panel stays on Loading… in a background tab (hidden page never does the first fetch) #259).
  5. Concurrency: N Bots (tree fixture), wall time and peak RSS.
  6. Timeline on vs off overhead.
• Optional team scenarios once Deployment step 1: official image and one isolated instance per person #352 exists: approval latency across two instances, board load with 200+ cards.
• Artifacts: JSON metrics + a short summary; fail the job only when a metric regresses past a threshold (warn first for a few days).

Dashboard

• One page (GitHub Pages, or a simple HTML report attached to the workflow run and linked from README) showing:
  • Last night's numbers vs 7-day median.
  • Trend charts per metric.
  • Pass / warn / fail for each scenario.
• Links from the daily release note (Release cadence: at least one tag per day, small and stable #351) and from Performance baseline: measure current smoothness (help wanted) #356 once the baseline table is filled.

Acceptance

• Nightly job runs without manual steps and publishes artifacts every night.
• Dashboard shows at least the 5 personal-mode metrics above for the last 7 days.
• A deliberate slowdown in a fixture causes a warn or fail within one night.
• No secrets or personal content in artifacts.
• Docs explain how to add a new scenario and how thresholds are set.

Open questions

1. Host the board on GitHub Pages, in the repo as committed history, or both?
2. Absolute thresholds vs relative (e.g. 20% worse than 7-day median)?
3. Mock model only, or also a cheap real model for end-to-end latency?
4. Who owns reviewing the board each morning?

Process

CI and dashboard work go through cloud OpenCode, review via Codex; bots do not hand-write code. Use results from #356 to pick the first thresholds.