fix(core): keep completed tool guardrail results when a resumed append fails - #4651

Summary

On a resumed turn that resolves one approval while another stays pending, the run publishes that turn's tool guardrail results only inside the NextStepInterruption branch, and that branch sits after the resumed Session append:

save_resumed_turn_items(...)            # can raise
...
if isinstance(turn_result.next_step, NextStepInterruption):
    tool_input_guardrail_results.extend(turn_result.tool_input_guardrail_results)
    tool_output_guardrail_results.extend(turn_result.tool_output_guardrail_results)

When that append raises, the approved tool has already executed and both its input and output guardrails have already returned, but nothing carries their results into RunState. The run-level lists die with the raised call, and RunState only ever receives guardrail results from a built result (result.py), which never happens on this path. Nothing republishes them later either, because the recovery resume does not re-execute the tool. So the results are gone permanently: absent from the checkpoint, from its serialization, and from the final RunResult.

Measured with an allow-only input guardrail and an allow-only output guardrail on the approved tool, across sync and streamed and across a live state and a JSON round trip. ran is how many times each guardrail actually executed:

before   ran=(1,1)   state=(0,0)  serialized=(0,0)  final=(0,0)     0/4 rows retain them
after    ran=(1,1)   state=(1,1)  serialized=(1,1)  final=(1,1)     4/4

The change publishes them next to the other resumed state updates, before the append, in both run.py and run_loop.py. Both paths already seed their run-level accumulators from RunState once at run start, before the turn loop, so writing the turn's results into state mid-turn cannot double count. Confirmed on the clean path, which still reports (1, 1) and not (2, 2) in both sync and streamed.

This is the second defect reported in #4646. It is independent of #4650: different root cause, different files, and the two diffs do not touch the same functions. #4650 makes the durable Session recover the dropped append; this one makes the completed guardrail results survive the same failure. Either can land without the other.

Test plan

tests/test_run_impl_resume_paths.py::test_failed_resumed_append_keeps_completed_tool_guardrail_results, parametrized over streamed and non streamed and over a live state and a JSON round trip. It pauses on two approval-gated calls in one response, approves only the first, fails the resumed append, then asserts the checkpoint and its serialization each retain one input and one output guardrail result, and that the final result still reports them after the second approval is rejected.

Verified it fails without the source change by reverting src/ and rerunning: all four cases fail.

.agents/skills/code-change-verification/scripts/run.sh passes end to end: format, lint, typecheck and the full test suite.

Issue number

Partially addresses #4646

Checks

• I've added new tests, if relevant
• I've run .agents/skills/code-change-verification/scripts/run.sh
• I've confirmed all verification steps pass
• If using Codex, I've run /review before submitting this PR

Second half of the same issue, split out because the root cause is a different one and I did not want to bury two fixes in one diff. I'm a freshman in college and still learning this part of the runner, so the thing I'd most like checked is my claim that publishing before the append cannot double count. I reasoned it from the accumulators being seeded once at run start and then verified the clean path stays at one result each, but you know the ordering here far better than I do.