The run history can be silently truncated by one bad fetch of the published gh-pages copy

[gaurav]

gh-pages is written by a force-push of a single commit, and read over HTTP by the same pipeline that writes it. Nothing coordinates the two, and there is no stated answer for what a reader sees mid-write.

The concrete case is the history file. Each run does this:

1. curl the published history.jsonl from https://translatorsri.github.io/babel-validation/data/history.jsonl;
2. append one line for this run;
3. force-push the whole site, including the new file, as a single commit.

Step 1 is a read of the live site, which is the source of truth precisely because step 3 replaces the branch rather than appending to it. That is a reasonable design — but it means the history is only as durable as that one fetch:

• A failed or empty fetch silently truncates the history. curl -fsSL on a 404 or a network blip means the run starts from nothing, appends its own line and publishes a one-line file. Every prior run is then gone, because the branch is replaced, not amended.
• The Pages CDN caches for ~10 minutes. The workflow header already notes that a dispatch shortly after a deploy can read a stale copy and drop a line. With Replace the website with a daily cross-environment test dashboard built around promotion drift #120 making a manual dispatch cancel a running build, two runs in quick succession are now easier to trigger.
• A second workflow writing the branch makes it worse. Whatever replaces the milestones page (Publish a daily cross-repository Babel milestones page as part of the dashboard site #112) has to publish through the same deploy for this reason as well as the clean-exclude one.

Worth deciding rather than patching around: options include keeping history.jsonl in the repository instead of only on gh-pages (making it a real append log with git history behind it), reading it from the gh-pages branch by checkout rather than over the CDN, or keeping the published file but refusing to deploy a history shorter than the one just read — a guard that turns silent truncation into a failed run.

Noticed while working on #120; not something to fold into it, since it is a design call about where the run history actually lives.