[jacebenson]

Summary

The dev channel has not received a release commit since v4.5.1. promote-main-to-dev.yml only triggers on push to main, and release-prod.yml pushes the version-bump commit with GITHUB_TOKEN, which starts no push workflow. Every release therefore leaves dev one commit behind, and dist-tag dev drifts further from main over time.

This adds workflow_dispatch to the promotion workflow and dispatches it from the release workflow right after the release commit lands.

Evidence

• Before: npm view @jacebenson/jsn dist-tags reported { latest: '5.0.0', dev: '4.5.1-dev.120.1' } while main was at 2335b0a chore: release v5.0.0.
• gh api repos/jacebenson/jsn/compare/main...dev reports behind_by: 2, ahead_by: 0.
• Last promotion run was push at e630e345 (the final feature merge), before the release commits. No promotion run exists for the v5.0.0 release.
• Workflow inspection: promote-main-to-dev.yml had on: push only, so the documented GITHUB_TOKEN limitation had no recovery path.
• After this branch is on main, a dispatched promotion is testable: gh workflow run promote-main-to-dev.yml --ref main.

Checks

• YAML parses for both workflows (yaml.safe_load), with promote-main-to-dev now exposing ['push', 'workflow_dispatch'].
• Step order in release-prod.yml is push release commit and tag, then dispatch promotion, then dispatch npm publish, then create the release.
• CI on this PR covers the workflow change with YAML syntax; the cli and site jobs skip because no application paths changed.

Merge danger

• Door: two-way. Two workflow files, no application code, nothing persisted.
• Blast radius: the dev channel mirror and prerelease publishing after each production release. Production publishing is unchanged and still gated by workflow_dispatch plus the v*.*.* tag.
• Rollback: revert the commit. dev stays whatever it is at that moment and the earlier manual-dispatch path is gone again.

Limitations

• The dispatch step cannot be exercised until the workflow exists on main; I verified the promotion job by dispatching the branch ref, not by running the edited release workflow end to end.
• Promotion still uses --force-with-lease against the fetched dev SHA, so a concurrent dev write fails the job rather than being overwritten.

Refs #392