Publish releases from version tags; add RELEASING.md

[jadamcrain]

What

• Release job: pushing a tag X.Y.Z runs the full CI. If everything passes, a release job:

  1. Checks that the tag matches the Cargo.toml version, that CHANGELOG.md has a ### X.Y.Z ### section, and that the tagged commit is on main.
  2. Publishes to crates.io, skipping if that version is already published.
  3. Opens a draft GitHub release whose notes are the version's changelog section, skipping if the release already exists.

  Because each step skips work already done, rerunning a failed release is safe. This follows the same model as dnp3 and rodbus: bare tags, publish only from tags, a draft release.

• Packaging check on PRs: CI runs cargo publish --dry-run.

• RELEASING.md: the human steps around the tag. They are: a Release X.Y.Z PR that bumps the version and finalizes the changelog, then tag main and push the tag, then review and publish the draft release. Also covers changelog conventions.

Needs one-time setup before the first tagged release

Publishing uses crates.io trusted publishing, so there's no API token secret. scursor doesn't have access to dnp3's CRATES_PUBLISH_TOKEN, which is a dnp3 repo secret. A crate owner needs to add a trusted publisher in the crate's settings on crates.io:

• owner stepfunc
• repo scursor
• workflow ci.yml
• no environment

Verification

GitHub Actions can't run locally, so I extracted each release step's shell script from the workflow and ran it with test inputs:

• Tag checks: a matching tag passes. A version mismatch, a missing changelog section, and a commit not on main are each rejected.
• crates.io check: 0.5.0 is detected as already published; 0.5.1 isn't.
• Release notes: they come out as exactly the version's changelog section.
• Packaging: cargo publish --dry-run passes.

The tag-triggered path itself first runs for real when 0.5.1 is tagged.