ci: add workflow_dispatch trigger to publish workflow

[vanceingalls]

What

Add a workflow_dispatch trigger with a version input to .github/workflows/publish.yml so the publish workflow can be re-run manually for a given tag.

Why

v0.4.11 was pushed to origin with the same git push origin main --tags that pushed main, but GitHub never delivered a push event for the tag ref. Result: the tag exists at acce912, the package was never published, and recovery required tag surgery (git push origin :refs/tags/v0.4.11 && git push origin v0.4.11).

This is a rare but documented webhook coalescing issue. Adding a manual trigger gives us a one-click recovery path so the next occurrence doesn't need to delete and re-push tags.

How

• Adds workflow_dispatch.inputs.version (required string) — describes the format and notes the tag must already exist.
• Extends the job-level if to allow github.event_name == 'workflow_dispatch' alongside the existing push and merged-PR conditions.
• actions/checkout@v4 now sets ref: refs/tags/v on dispatch so we publish the exact commit that was tagged, not whatever is currently on main. Push and pull_request continue to use github.ref (no behavior change).
• Resolve version reads from inputs.version on dispatch (strips an optional leading v for forgiving input).
• Create release tag is intentionally not extended to dispatch — the dispatch path assumes the tag already exists (that's the whole reason you're using it).
• Per-package npm view and gh release view idempotency guards already exist, so a partially-completed publish or re-run on an already-released version is safe — published packages are skipped, the GitHub Release isn't recreated.

Test plan

How was this tested?

• Manual testing performed — bunx oxfmt --check passes; YAML parses cleanly; diff reviewed against existing workflow_dispatch usage in .github/workflows/windows-render.yml. End-to-end validation will be the next time this fires (either organic tag push or manual dispatch on an existing tag).