feat(node): on-demand per-session CPU/memory profiling (#244)

[Davidemulo]

Summary

Adds profiling triggerable via API, recording CPU/memory per proof-generation phase — with one deliberate deviation from the issue's literal "export as pprof or flamegraph-compatible format": the actual MPC compute work for a session runs in co-noir child processes (session::run_proof_generation spawns one per phase — merge_shares, witness_generation, proof_generation), not in this node's own call stack. An in-process sampling profiler (the pprof crate) would see almost nothing, since none of the expensive work executes on this process's stack. See services/node/docs/PROFILING.md for the full rationale.

Instead, profiling samples each co-noir child process's OS-reported CPU% and memory on a 200ms interval for the duration of its phase, exported as JSON per phase (duration, peak memory, avg/peak CPU%) rather than the pprof wire format, since pprof's call-graph model doesn't apply to an opaque external process this node has no stack visibility into.

Changes

• src/profiling.rs (new): ProfileRegistry (which sessions have profiling enabled + what's been collected so far) and sample_process_until_exit (the sampling loop, spawned as its own task per phase).
• session.rs: new run_profiled() helper wraps each co-noir subprocess call. When profiling isn't enabled it's exactly cmd.output().await — zero extra cost; when it is, it spawns the child with piped stdio and starts a sampler task against the child's pid. A retried proof_generation attempt (existing transient-failure retry loop) appends another phase entry rather than overwriting.
• api.rs: POST /session/:id/profile enables profiling for a session (must be called before /generate); GET /session/:id/profile returns the collected SessionProfile as JSON, 404 if never enabled. post_generate only threads the registry through when the session was explicitly enabled — profiling is strictly opt-in.
• main.rs: NodeState gains a profiling: ProfileRegistry field and the new route.

No new dependencies — built entirely on sysinfo and tokio::process, both already direct dependencies (sysinfo is already used the same way for the node's own memory metric in main.rs's background updater).

Rebase note

This branch was rebased onto upstream/main after creation, which had gained an unrelated per-phase timeout watchdog (PhaseTimeouts, added as a new parameter to run_proof_generation) in the meantime — merged cleanly alongside the profile parameter, since the two don't interact.

Acceptance Criteria

• Built-in profiling that records CPU and memory usage per MPC session phase
• [~] Export as pprof or flamegraph-compatible format — exports structured JSON instead, with the rationale documented in docs/PROFILING.md (pprof's model doesn't apply to sampling an opaque external process)
• Trigger profiling on demand via API — POST/GET /session/:id/profile

Tests

src/profiling.rs's tests module: ProfileRegistry enable/is_enabled/get semantics (per-session isolation, idempotent re-enable that doesn't clear prior phases, None for a never-enabled session), phases append rather than overwrite across the three phase names, and one #[cfg(unix)] test spawning a real short-lived sh -c "sleep 0.3" child to confirm sample_process_until_exit records a phase with non-zero duration once it exits.

Verification

No local Rust toolchain is available in this environment (link.exe fails compiling proc-macro2/quote build scripts). cargo test -p mpc-node could not be run here. Verified by close manual review, including checking the run_profiled call sites against the freshly-merged watchdog deadline checks to confirm no collision. Would appreciate CI/a reviewer confirming locally.

Closes #244

[drips-wave]

@Davidemulo Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits