feat(serve): --demo 用内置示例数据启动看板

[modusensus]

看板只从真实的配置与守护进程状态文件取数据。于是"先看一眼前端长什么样"这件事以前只有
两条路：对着真基础设施跑，或者手搓一份状态文件。后者会随 payload 契约漂移而悄悄失真，而它
长得和真数据一模一样——最容易被当成真的。

这个 PR 把演示数据收进产品：ponte serve --demo 不读配置、不碰守护进程，用一份内置的
确定性时间轴驱动同一个 HTTP 服务。

时间轴：为什么是纯函数而不是定时器线程

数据是"现在 − 启动时刻"算出来的，所以页面每次轮询都会取到一个新的、自洽的状态，而同一
时刻永远是同一份 payload。这带来两个具体好处：

• 测试钉的是时刻，不是运气——tests/test_demo.py 里没有一处 sleep；
• 不需要后台线程去改状态，也就没有"谁在什么时候读到了半个状态"的问题。看板本来就是轮询
  接口（/status.json 从不缓存），采样由它自己提供。

三个 profile 覆盖看板会渲染的每一种状态，周期互质（180/120/210 秒）所以变化会错开：

profile	周期	看到什么
web	180s	健康 140s → 断线 6s → 重连退避 18s → 又连上 16s（会话 +1、在线率掉下 100%）
db	120s	连上了但服务器端口没监听（确定失败，25s：本地在听、远程没听）→ 断线 → 长退避
metrics	210s	健康 170s → 探针得不出结论 40s：端口是"未观测"而不是"未监听"（#25 的语义）

db 那条是专门放的：它让"健康是确定失败"和"可用率不高"同时成立，而这两列本来就不是一回事；
metrics 那条让 未观测 与 未监听 在页面上真的能被区分开。

数据在三处自证是演示

一张看板截图里写着服务器地址与端口，它不该被误读成某个人的真实基础设施：

1. /status.json 与 /metrics 的 payload："demo": true；
2. 页头 演示数据 徽记 + 页脚说明（标在 payload 上而不是服务端开关上，所以原地刷新不会把
   它刷没）；
3. 命令行一行黄字。

示例主机名一律 example.com。绑定校验照旧：非回环 --host 仍然要求令牌，演示数据一样
是一张内网拓扑图。

顺带修掉一处自相矛盾（看着运行中的看板发现的）

启动后的第一个周期里还没断过线时，"上次断线"会回头去取上一轮——而那一轮根本没发生过。于是
页面写出 "已运行 0h 1m 20s" + "上次断线 0h 2m 0s前"：一条比进程本身还老的故障记录。

现在启动后的第一个周期内没断过线就是没断过（显示为空）。这条钉进了测试：沿全时间轴扫描，
任何记录（事件流、上次断线、会话起点、上次通知）都必须落在 [启动时刻, 现在] 之间。
反向对照跑过：把修复改回旧写法，新测试红，报的正是 assert 999960.0 is None。

验证

• pytest 432 passed（tests/test_demo.py 新增 12 条），覆盖率 87%+；
• ruff / mypy（本机与 --platform linux）/ _smoke_test.py 全绿；
• payload 契约测试：直接拿 ponte.main._status_payload 的真实输出来比键集合，而不是抄一份
  清单自己维护——这份数据是手写的，契约以后长出新字段时它会悄悄落后，而它看起来完全一样；
• 反向对照：确认过新测试真的抓得住旧行为（见上）。

边界，说清楚

• 演示数据里没有真的 SSH 进程，模拟的是守护进程已经攒下的统计（会话、尝试、可用率、事件
  流），不是真的在连 example.com；想连真隧道请用真实配置跑 ponte serve；
• 重启进程会把时间轴从头开始（启动时刻就是时间原点）；
• 这条 PR 不改动 HTTP 层的任何东西：看板本来接受任意 provider() 可调用对象，--demo 只是
  换了一个 provider。

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.