Add some kind of edition tracker inside the generated EPUBs

[domenic]

It'd be nice, if one sees a worm-scraper-produced EPUB in the wild, to know what version it is, and therefore how many of the text fixups it has.

The ideal version of this would only count changes that cause different EPUB outputs, but I don't think that's feasible without error-prone manual updates. So we'll probably just inject the worm-scraper version.

[domenic]

If we can get a date instead of a version number, then at least in EPUB 3, it looks like <meta property="dcterms:modified">...</meta> is the way to go here.

We should also probably include publication date.

[domenic]

As of fba981f there is a dcterms:modified giving the date that the edition was built.

This isn't fully satisfactory, because we would ideally want to output the same version/modified date for multiple people building at separate times, as long as the contents are the same.

Possible improvements:

• Embed multiple dates, one for the source text and one for the worm-scraper update, only allowing one of them to be the dcterms:modified that will show up in (some) ebook readers.
  • It's still kind of annoying to get the worm-scraper publication date. I guess we could query the npm API?? That's a bit silly though... A prepublish hook that adds the date in a text file, maybe, is the way to go.
• Don't use dates, at least for the worm-scraper version; just use invisible custom metadata corresponding to the package version number.

Rejected ideas:

• max(latest date any source text is updated, latest publication date of worm-scraper).

  • Rejected because this doesn't work well in edge cases. E.g. if a worm-scraper version is published 2024-11-06 and another 2024-11-08, and then the source text is updated 2024-11-10, both the old and newer worm-scrapers will produce the same date (2024-11-10). Similarly for if there's a worm-scraper update after source text modification but people are holding on to old source text.

• Use neither dates nor version numbers, but instead content hashes.

  • Rejected because content hashes aren't comparable so you can't tell whether a produced EPUB is "better" than another.

• Try to combine both worm-scraper version info and content version info into a single version string, or pseudo-date.

  • Rejected because this is a fundamentally two-dimensional problem.