[Bug] reconstruct_run_result drops StepInfo.tools from persisted trajectories

Commencez par reconstruct_run_result et la construction de StepInfo qu’il utilise, puis examinez le chemin existant de sérialisation des trajectoires. Ajoutez une couverture pour un round trip contenant StepInfo.tools et vérifiez que l’étape reconstruite conserve les informations d’outil d’origine, y compris lors de réexécutions uniquement destinées à l’analyse.

I noticed that reconstruct_run_result does not restore the tools field of persisted trajectory steps.

A serialized StepInfo can contain tool information such as:

{
    "step_id": 1,
    "tools": [
        {
            "name": "browser",
            "description": "Browse a web page",
        }
    ],
    "assistant_content": {
        "content": "Done",
        "reasoning_content": "",
        "tool_calls": [],
    },
    "metric": {},
    "observation": [],
}

After passing this payload through reconstruct_run_result, the restored step contains:

restored.trajectory.steps[0].tools == []

The function restores assistant content, metrics, prompts, observations, and timestamps, but does not pass raw_step["tools"] to StepInfo.

This breaks lossless serialization and can make analysis results depend on whether they are produced during the original run or recomputed from persisted results. Analyzers that inspect step.tools, including the hack detection analyzer, may receive different inputs during an analysis-only rerun.

The expected behavior is for the reconstructed step to preserve the original tool information.

A possible fix is to restore the field when creating StepInfo:

tools=raw_step.get("tools", [])

A round-trip regression test could verify that serializing and reconstructing a trajectory preserves this field.

I reproduced this on revision 16cb375779271d4524cde785d1656e1fc4528fac with Python 3.11.9. No model or external API is required.

I'd be happy to work on the fix and add the regression test. Please let me know if this approach looks reasonable.