Write the run timestamp into task_info.yaml

[rcannood]

Describe your changes

timestamp is a required field of the results schema:

// common/schemas/results_v4/task_info.json
"timestamp": {
  "description": "ISO 8601 timestamp of when these results were generated.",
  "type": "string",
  "format": "date-time"
},

but nothing was writing it, so render_results_report has been guessing: it parses a
date out of a run_<date> results path, and falls back to the modification time of
task_info.yaml if the path does not have one. Our last run only came out right
because run_full_denbi.sh happens to name the publish dir run_$(date ...) -- a
results path without a date in it, or a file that got copied around after the run,
gives a wrong timestamp or none at all.

run_benchmark now writes it, next to the commit from #33:

name: task_spatial_simulators
version: build_main
commit: 2dc5486b62cc1dc65b0abf371be898f8c246027e
timestamp: '2026-07-30T13:36:58Z'
...

It is the launch time rather than the completion time, because workflow.complete is
only known once the run is over, and this closure runs before that. That also lines up
with the run_<date> directory name, which is what the reporting side was inferring
from anyway.

Checked against Nextflow 26.04 that workflow.start is an OffsetDateTime, that
.toInstant().truncatedTo(SECONDS).toString() gives 2026-07-30T13:36:58Z, that
snakeyaml quotes it so it stays a string rather than a YAML timestamp, and that
yaml::read_yaml() reads it back as a character -- so it passes ajv's date-time
check. Also checked that it resolves inside the joinStates closure, where it is only
evaluated at execution time.

No change needed on the reporting side this time: get_task_info already prefers the
timestamp from task_info.yaml over its --timestamp argument. I will send the same
to task_template together with the commit field.

Checklist before requesting a review

• I have performed a self-review of my code

• Check the correct box. Does this PR contain:

  • Breaking changes
  • New functionality
  • Major changes
  • Minor changes
  • Bug fixes

• Proposed changes are described in the CHANGELOG.md

• CI Tests succeed and look good!