fix(system-status): return seconds-since-start, not epoch, for uptime

[shiba4life]

Summary

/api/system/status.uptime was returning SystemTime::now() - UNIX_EPOCH — a Unix timestamp (~1.78e9), not an uptime. Any UI rendering "uptime" from that field showed ~56 years.

/api/health already had the right pattern: a process-global SERVER_START: OnceLock<Instant> recorded once in FoldHttpServer::run via mark_server_start(), then read with SERVER_START.elapsed().as_secs(). This PR extracts that read into a new pub fn server_uptime_secs() -> u64 next to mark_server_start (so the two endpoints can't drift), and replaces the SystemTime arithmetic in src/handlers/system.rs with the helper.

Wire shape and field name unchanged — the frontend continues consuming uptime: number.

Before / after

# Before (origin/main)
$ curl -s -H "X-User-Hash: <hash>" http://127.0.0.1:9102/api/system/status
{..., "uptime": 1778285378, ...}                          ← wrong (epoch)

# After
$ curl -s -H "X-User-Hash: <hash>" http://127.0.0.1:9102/api/system/status
{..., "uptime": 5, ...}                                    ← seconds since start

# /api/health was already correct, still is
$ curl -s http://127.0.0.1:9102/api/health
{"ok":true,"uptime_s":5,"version":"0.4.0-..."}

Regression guard

test_system_status now reads the response body and asserts uptime < 1_000_000. A fresh test process is alive for at most a few seconds, so the bound is generous, while an epoch reintroduction (~1.78e9) would trip it instantly.

Test plan

• cargo build --workspace clean
• cargo clippy --workspace --all-targets no new warnings (only pre-existing apple_import.rs build_attendee_ingestion_records macOS-only dead-code warning, not exercised in Linux CI)
• cargo test --workspace --tests system_status passes including the new bound assertion
• CI (Linux) clippy + tests green

Out of scope

• uptime JSON field name kept as-is (frontend dependency)
• /api/health left untouched
• SystemStatusResponse shape unchanged

🤖 Generated with Claude Code