Publish or document release tags for the README-pinned runtime

[coygeek]

Summary

The README currently instructs users to install a reviewed v0.2.25 source commit directly from GitHub, but the repository's public GitHub Releases list currently shows v0.2.15 as the latest release.

That makes the install surface confusing for first-time users and agents: the documented runtime appears newer than the latest published release artifact.

Evidence

The README install command pins this source commit:

python3 -m pip install \
  'deploybot-merge-queue[mcp] @ git+https://github.com/Forward-Future/DeployBot.git@12c6c03aa76a553fa4068279baa29e90a30bbeb1'

The package metadata in the cloned source reports:

[project]
name = "deploybot-merge-queue"
version = "0.2.25"

But gh release list --repo Forward-Future/DeployBot --limit 20 reports DeployBot v0.2.15 as the latest published GitHub release.

Impact

Users evaluating DeployBot can reasonably interpret this as one of:

• the README points to an unreleased runtime;
• the latest GitHub Release is stale;
• the source commit is the intended canonical release channel;
• the package version is ahead of the release process.

For a privileged merge coordinator, that ambiguity matters. Operators need to know which exact runtime has been reviewed, published, and recommended for GitHub Action installation.

It also makes agent-led setup harder because an agent cannot safely infer whether to trust the latest release, the README commit, or the current default branch.

Proposed fix

Pick one canonical release story and make it explicit:

1. Publish GitHub Releases/tags through the current README-pinned version, including v0.2.25, or
2. Update the README to state that source-commit pins are currently the authoritative reviewed runtime and GitHub Releases may lag, or
3. Change the README to install from the latest published release/tag instead of an unpublished source commit.

If source-commit pins remain the intended release channel, consider adding a short "Release channel" section that explains:

• why the README pins a commit instead of a tag;
• whether the commit is expected to match pyproject.toml version;
• how users should discover the current reviewed pin;
• whether old GitHub Releases should be ignored.

Acceptance criteria

• A new user can tell whether the README-pinned commit or GitHub Releases are the canonical install surface.
• The README no longer appears to reference a newer runtime than the latest public release without explanation.
• The GitHub Action example and README install command agree on the same reviewed runtime identity.
• deploybot doctor version-drift guidance remains consistent with the chosen release channel.

Verification

• gh release list --repo Forward-Future/DeployBot --limit 20
• Inspect README.md, examples/github-workflow.yml, and pyproject.toml for a consistent runtime version/pin.