feat: support for prereleases

[chris11-taylor-nttd]

Missed this in a prior update. Adds support for the prerelease functionality we're using in launch-terraform-skeleton.

Drops run_post_release_workflow, which never got implemented and isn't used by any callers.

[bryce-lynn-nttd]

PR Review

Overall: This is the clean unblocker for launch-terraform-skeleton#20 — landing the feat/prerelease-on-merge work on main so callers can pin to a real tag rather than a feature-branch ref. Adds prerelease_identifier and publish inputs to reusable-release-on-merge.yml, threads both into the existing release-drafter@6a93d829 step (replacing the previously-hardcoded publish: true), removes the unused run_post_release_workflow input, and adds a clear docs section walking through the rc0 → rc1 → draft-rename cycle.

Verifications:

• release-drafter@6a93d829 supports both new inputs. Confirmed prerelease-identifier (line 46) and publish (line 31) on its action.yml at the pinned SHA.
• No callers of the removed run_post_release_workflow input outside this file. Org-wide code search returned only the file being modified.
• Only existing caller of prerelease_identifier in the org is launch-terraform-skeleton/.github/workflows/prerelease-on-merge.yml — exactly the file currently broken on skeleton PR #20.
• Defaults preserved: publish: true matches the previous hardcoded behavior, so all existing callers (the template-distributed release-publish.yml in module repos and the eight launch-terraform-skeleton workflow refs) keep working without changes.

CI green; no prior reviews.

Non-blocking

1. Commit type could arguably be feat!: rather than feat:. Removing run_post_release_workflow is technically a breaking change to the workflow's input contract — any future caller passing that input would hit startup_failure (we empirically verified that behavior yesterday in a sandbox). Practically harmless because no consumers exist today, but a strict reading of Conventional Commits would mark this feat!:. Your call; the PR body discloses the removal clearly so I wouldn't pedantic-block on this.

2. Disposition of skeleton PR #20. Once this lands and a tag is cut, the path forward there is either (a) update PR #20 in place to repoint prerelease-on-merge.yml at the new SHA, or (b) close it and open a fresh PR with the corrected reference. Worth a one-line note on PR #20 once the tag exists so the chain is visible.

Generated with Claude Code (Opus 4.7)

[chris11-taylor-nttd]

1 is intentional, I'm going to purposefully bump the major version at the end of all of this.