Say that the tags and releases are backfilled, now that they are

[marknolan]

The tags and releases are backfilled, so the two files that described their
absence are now wrong.

What was done to the repo

Every version from 0.1.0 has a tag, every stable one a release page, and the
seven 0.1.8-dock.N prereleases have tags without release pages. 40 tags, 33
releases, where there were 9 and 8. Each tag sits on the commit that carried
its version — a dozen of those commits name their own release in the subject
(DEV-976: release 0.1.24 with the ExG configuration codec), which is what
makes the mapping checkable rather than asserted.

v0.1.5 turned out to have been tagged in May but never released; it has a page
now too, so v0.1.1–v0.1.7 is an unbroken run.

v0.4.1 keeps the Latest badge — every backfilled release was created with
--latest=false.

What the backfill cannot do

Conjure artifacts. Cut Release is the only thing that publishes, and it never ran
for 0.1.8 through 0.3.0, so those tags mark commits and nothing more. Both
files now say so plainly, because a release page ordinarily implies a published
package and here it does not.

One cosmetic consequence, unavoidable through the API: a backfilled release's
date is the date it was created, not the date the version shipped, so the
releases page lists this block above v0.4.1. Each body states the original
release date and that it was backfilled.

🤖 Generated with Claude Code

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}