Add a Pareto frontier to DSEReport alongside the single best step

[shreyaskommuri]

Context

@podkidyshev, separate proposal from #993 (closed) and #994 (open). Different part of the codebase, reporting rather than search strategy, flagging that distinction up front given how #993 went.

While building CloudAI-Autotune, I ran into the same gap here: recommend --joint reports the best combination tried in a sweep plus the Pareto frontier (every combo not strictly beaten on both throughput and latency by another). CloudAI's own DSE report only ever surfaces a single "best" step.

Unlike #993, this isn't a search-agent proposal, it doesn't touch how a sweep decides what to try next, only how the results of a sweep already run get summarized. That said, since you mentioned internal agents already exist, it's possible their own reporting already does something like this too. Wanted to ask directly rather than assume, same as last time.

Also flagging as before: used an AI coding assistant (Claude Code) for the code reading behind this and for drafting the issue text.

Problem

src/cloudai/report_generator/dse_report.py's get_best_step() picks a single trajectory step by one scalar reward, and that's the only "best" surfaced anywhere in the DSE report (the reward chart, the best-config dump, the metadata). If two metrics trade off against each other within a sweep (e.g. throughput vs. latency), there's no way to see that the throughput-best and latency-best steps are actually different configs, everything collapses into one number.

Proposal

Add a Pareto-frontier view alongside the existing single "best" step: every step not strictly dominated by another (i.e. no other step is at least as good on every tracked metric and strictly better on at least one). This is the same logic already shipped and tested in CloudAI-Autotune's _pareto_frontier:
https://github.com/shreyaskommuri/CloudAI-Autotune/blob/6f07b65/autotune/recommender.py#L642

Concretely: extend dse_report.py to compute the frontier over trajectory_steps (alongside get_best_step), and surface it in the report, e.g. a table listing each frontier step's config and metrics, similar to how the existing best-config section works. No new dependency, this is a pure function over data already loaded.

Open questions

• Which metrics define the frontier. Autotune's version is two-metric (throughput/latency) because that's all it tracks. CloudAI's agent_metrics can be an arbitrary list, does the frontier generalize to N metrics (any step not dominated across all of them), or should this start scoped to exactly two?
• Where it renders. Alongside the existing reward chart/best-config section in the same report, or as its own optional section?

Out of scope

• Not proposing any change to search strategy, agent selection, or handle_dse_job, this only touches how an already-completed sweep's results are reported.
• Not touching Support path-based test references in scenario files #994 or the parser work in Support relative-path test references and lazy-load only referenced test/hook tomls #985.

No PR yet per CONTRIBUTING.md, filing this first per the same process as #985 and #993.