Automate release drafting and redline base from git tags (new redlines)

[SteveLLamb]

Auto-create draft releases on pubState=pub merges

Whenever a merge to main results in pubState=pub, the tooling now auto-creates a draft GitHub release tagged YYYMMDD-{pubStage} from the doc's pubDateTime + pubStage. Editor reviews and publishes the draft, which fires the existing release-published flow (zip upload + template-repo dispatch) unchanged.

The redline base is now derived from git tags rather than a hand-maintained .smpte-build.json. When pubStage=PUB, against the most recent prior -pub tag (edition-to-edition); otherwise against the most recent prior dated tag of any stage (iterative draft review). .smpte-build.json kept as an optional override scaffold (NULL by default) so legacy docs and archival rebuilds still work.

Includes a [force-release] commit-message escape hatch for same-day workflow events (e.g. PCD opening from Pre-FCD on the same pubDateTime+pubStage) — appends -2/-3/... to the tag.

Annex sec-document-github-releases rewritten to describe the new automated flow. To be at least partially moved to new HTML Workflow AG later.

Closes #395, as it would longer apply in this workflow.

[github-actions]

Review links

Clean
Clean PDF
Redline to current draft
Redline to most recent published edition

[SteveLLamb]

Refactors the redline generation in the tooling and adds a new redline output:

• Redline to most recent published edition (pub-rl.html) — restored to its
  original PUB-only meaning: always against the most recent prior *-pub tag.
  Satisfies the AG-02 requirement for a redline against the published baseline
  when preparing a revision.
• Redline to most recent release (release-rl.html) — NEW. Generated
  against the most recent prior dated tag of any stage (-wd/-cd/-fcd/
  -dp/-pub) when the document's pubStage is a draft stage. Skipped when
  pubStage is PUB, since a published edition's relevant comparison is to
  the prior published edition only. Satisfies the AG-02 requirement for
  ballot-document markup during comment resolution.
• Both redlines are produced on every PR, push to main, and release publish
  (subject to the PUB skip above). Both are bundled into the review zip
  attached to published releases. Tag lookup tolerates -N suffixes from
  [force-release] builds and excludes any tag pointing at HEAD so a
  freshly-tagged release does not redline against itself.

A new sec-redlines section in doc/main.html documents all three redline
outputs (including the existing PR-time Redline to current draft) in one
place, with cross-references from the build-config and release-workflow
sections.

[SteveLLamb]

Confirmed working and releases auto generated and new redlines working in https://github.com/SMPTE/html-pub-test

[thomasheritage]

The terminology used for the redlines was brought up in #40 -- it would be good to address/dispose of that issue as part of this PR

[thomasheritage]

As commented in #312 (comment), does the AG 33 workflow mean that the redlines base-rl.html and release-rl.html will always (in practice) be identical?

[thomasheritage]

https://doc.smpte-doc.org/html-pub/feature/release-tag-automation says for "Redline to current draft (base-rl.html)"

shows what the PR itself changes relative to the branch it will merge into.

This is (probably) not true unless you've changed something (I've not checked) since I wrote #389 due to a quirk in how GitHub Actions works (with the PR getting (temporarily) merged to the target branch before the code gets executed)