Fix: Add started_at/duration in SessionReport.to_dict() and drop a duplicated assignment

[TimCares]

Hello there! While working on monitoring voice AI agents I went through
JobContext.make_session_report/SessionReport
and found two small, self-contained issues. Both do not change the semantics of any existing field.

Summary

1. started_at and duration are never serialized. SessionReport defines
   both as fields, but to_dict never emits them. timestamp (the "end") is serialized, but the start and
   the duration are silently omitted, so they're computed/stored and then lost
   on serialization. Consumers of the serialized report (e.g. the local
   session_report.json written during console recording, and anything
   downstream reading to_dict()) can't see the session start or duration at
   all, even for audio sessions where duration is computed.

2. Duplicated assignment in make_session_report.
   audio_recording_path and audio_recording_started_at are set in the
   SessionReport-constructor call and then re-assigned again immediately afterwards.
   The second block is redundant for those two fields, only the duration line
   adds anything.

Changes

• Emit started_at and duration in SessionReport.to_dict().
• Remove the redundant re-assignment of audio_recording_path/
  audio_recording_started_at in make_session_report.

Backward compat

Adding the two keys to to_dict() is purely additive. No existing field changes
meaning or type, so consumers (including Cloud observability) are unaffected.

Out of scope

There's a related but separate design question —> what duration even is
and whether it should be gated on audio recording.
That changes the meaning of an existing field.
I'm intentionally keeping that out of this PR.
I'll open a design discussion and link it in a comment below.

[CLAassistant]

All committers have signed the CLA.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[TimCares]

As mentioned above, I opened a separate design discussion:
What SessionReport.duration should mean semantically
and whether it should depend on audio recording (it currently is, so non-audio
sessions get duration = None):

#6259

I am keeping this out of this PR since it would change the meaning of an existing field
and is worth agreeing on first. Would follow up with a PR there once the
semantics are cleared.