feat(daemon): report resident memory in daemon info/status so leak reports carry numbers (#1360) #1785

Summary

fbuild-daemon can reach ~3.9 GB RSS and stop answering /health (#1360), and every report of it so far — including the measurement I just ran — depends on an external sampler (tasklist, ps, /proc) because fbuild exposes nothing about its own memory. fbuild daemon status shows state, pid, operation, uptime: no resident size, no trend.

That gap is why #1360 took months to characterise: by the time anyone looks, the evidence is a screenshot from another tool.

Proposal

Report resident size from the daemon itself, so the timeline is available during and after the event:

• /api/daemon/info gains rss_bytes (and peak_rss_bytes, which is what a wedged daemon is judged by).
• DaemonStatus (the on-disk status file, crates/fbuild-daemon/src/status_manager.rs) gains rss_bytes, refreshed on the existing maintenance tick — cheap, one Option<u64>, and it survives the daemon dying, which the HTTP endpoint does not.
• fbuild daemon status prints it next to the pid.

Acceptance criteria

• A value is reported on Linux, macOS and Windows through fbuild_core::platform::process (no raw cfg!, no /proc reads outside the platform tree; the boundary scanner already owns this).
• None — not a bogus zero — when the host cannot report it (older kernel, permission, recycled pid).
• A test asserts the field round-trips through the status file, and that a daemon started without the capability still serialises.
• Post-dump heap_dump response (already shipped, perf: adopt the mimalloc-pprof allocator for heap/leak profiling; verify on-CPU, off-CPU, and symbolization from running-process #1361) and rss_bytes agree directionally: a leak large enough to wedge the daemon shows up as growth in both.

Notes

• Adding these fields means touching every DaemonInfoResponse literal (handlers/health.rs, broker/backend.rs, the models.rs test module), so it is one PR, not a drive-by.
• Not to be confused with CI: board build jobs flake with 'daemon did not become healthy after 3 spawn attempts' (2 release dry runs in a row) #1627: the spawn-budget and readiness diagnostics there are already shipped; this is about memory observability.
• Measurement that motivates it: idle daemon on main 2ba57549 held 84–90 MiB RSS flat for 8.75 min (peak 181.8 MiB HWM), 148 live heap samples — i.e. the mechanism works and is cheap enough to always-on log at a coarse interval.