Results age silently: no run date and no framework version on the board

[nigrosimone]

Every number on the board is published without a date and without the version of the framework it
was measured with. Today nothing is very old, so it does not hurt yet, but in a year a row measured
once and never re-run will look exactly like a fresh one. What is missing now cannot be recovered
later, so I think it is worth adding before it is needed.

1. Record the run date and the measured version

Both have to be written when the benchmark runs, in save_result() (scripts/benchmark.sh), inside
the result JSON. The date cannot be taken from git history: #1034 rewrote the results layout on
2026-07-24 and 66 of the 157 entries still point at that commit, so git log gives the migration
date and not the run.

The version should be read from the image that was measured, not from the manifest. The manifest is
not reliable today: 11 Dockerfiles still use latest or no tag (#471), and 13 of the 14
package.json entries use ^ ranges with no lockfile and npm install, so two builds of the same
commit are not the same versions. A small build step that writes the resolved version into the image
is honest also for an entry that is not pinned.

2. Show it, and mark old rows

version | measured <date> on the row, and a row older than about 12 months marked as stale (greyed
out, or a badge). A per-round date is not enough: entries are re-run one at a time, so the current
round already mixes measurements months apart. It would also help the timeline app of #357, which
today has to guess when a result changed.

3. Later: automatic dependency bumps

A bot PR per outdated dependency, like dependabot. The cheap half already exists: validate.yml
runs on frameworks/** and proves the entry still builds and passes, and if it fails we look at it
and fix the implementation. The expensive half is the re-measure: one runner, collaborator approval,
hours per run. So the bot should batch per language (/benchmark-multiple, #1084) and the run stays
a maintainer decision. One rule to keep: the published version must change only when a benchmark
really ran, otherwise the board would claim a version that was never measured.

[MDA2AV]

We are working to have automatic value updates every x weeks for all values for frameworks, engines and experimental likely excluded to save resources.

The plan is to have maximum 1 month old values in the table, this will be achieved by triggering runs here on github that execute benchmarks for all frameworks within a single test as for example baseline and we would do 2-3 of these per week, keeping values refreshed.

We are also aware that some entries may become stale with time and to be honest don't plan on updating them because that would break result repeatability, updating a framework should be the job of that entry maintainer in order to keep its values up to date, if possible the highest. For example some people may want to maintain an entry that is frozen in a specific version, and that is fine, everyone has access to the entry's source code and docker configs by simply clicking on each table row, ideally such data should also be present in the framework card.

The total number of frameworks we will automatically support and update is not unlimited, our threshold is estimated at 100-150 and if new entries go past that value, stale non maintained ones may be disabled in their meta.json, no longer showing in the website. We prioritize entries that implement more tests and have a mantainer specified in the meta.json file whom we can ping for issues.

[Kaliumhexacyanoferrat]

Version wise I would love to have this in the timeline, but I fear that there is no universal way of reading it from the project files as it is heavily technology dependent and an additional field in the meta.json would quickly diverge. But maybe it is worth a try ...