Adopt SemVer and publish releases from CI

[dsaiko]

The repository had exactly one tag — v2025.01, January 2025 — in a vYYYY.NN
shape used once and never repeated. Nothing said whether .01 was a month or a
counter, and three contract changes (#15, #16, #18) shipped untagged behind it.

Nothing enforced a release either: ci.yml already triggered on v* tags but had
no release job, so pushing a tag ran the schema check and produced nothing. That
is how a published contract ends up with one release in twenty months.

This fixes both halves.

The scheme, written into the README

vMAJOR.MINOR.PATCH, with the major tracking the contract generation rather
than this repository's history. v1.x.y describes wire v1 — the one behind the
/v1/ REST paths and the feed/v1 / rest/v1 SDK packages. A v2.0.0 would
only ever accompany a /v2/, which means a major bump is something clients are
told about rather than something they discover. Additive attributes and messages
are minor; corrections that do not change what the producer sends are patch.

This also brings the repo in line with every other Oddin contract repo —
protocol_buffers v0.1091.0, otsschema v0.29.0, bragischema v0.2.13, and the
three SDKs — where oddsfeedschema was the only CalVer outlier.

v2025.01 is referenced nowhere (not by the SDKs, not by docs), so it is left
in place as a legacy tag rather than continued.

The release job

A v* tag now publishes the GitHub release itself:

• Gated on needs: schema, so a tag whose schema does not compile cannot
  become a download. Given match_summary.xsd did not compile from before
  v2025.01 until Make the schema describe what the producers actually send #18, this is not hypothetical.
• Attaches oddsfeedschema-vX.Y.Z.zip containing schema/ alone. Consumers
  who regenerate bindings want the XSDs, not the fixtures and the checker that
  GitHub's own source archives carry.
• A release written by hand before the tag is pushed keeps its notes and only
  gains the asset — so a breaking change can still be explained properly, the way
  v1.0.0 was. A bare tag gets generated notes instead.
• A tag with a hyphen (v1.1.0-rc.1) is published as a pre-release, matching
  how the SDKs tag their release candidates.
• It elevates to contents: write per job, so the job that executes
  repository code keeps read-only.

Verified the three branches of that shell against a mock gh:

tag v1.1.0, no release yet  -> gh release create v1.1.0 …zip --title v1.1.0 --generate-notes
tag v1.1.0, release exists  -> gh release upload v1.1.0 …zip --clobber
tag v1.1.0-rc.1, no release -> gh release create … --generate-notes --prerelease

v1.0.0 is already tagged and released by hand, so the job first runs on the next
tag. No schema change here — make check still passes at 31 schemas, 41 payloads,
0 problems.

Note for whoever reviews this

The oddsfeedschema-main-ruleset sets require_code_owner_review, but the
repository has no CODEOWNERS file. Worth either adding one or dropping that
requirement.

🤖 Generated with Claude Code

[dsaiko]

Landed on main directly as db55490 — the two commits were squashed in rather than merged, so this PR has nothing left to merge. Closing keeps the linear history the ruleset requires.

Content is unchanged from what was reviewed here: README.md versioning + release process, and the release job in ci.yml.