Document git-tag/release versioning in README

[JesperSchulz]

Why

BCQuality is consumed at a URL and currently has no documented way to version releases or for orchestrators to pin one. The only version signal lives in plugin.json/marketplace.json (0.1.0), and consumers track main with no stable ref to bind to.

What

Adds a short Versioning section to the README that formalizes the simplest possible scheme: git tags and GitHub Releases, no new machinery.

• Semver vMAJOR.MINOR.PATCH, with rough guidance on what bumps what (MAJOR for consumer-facing contract breaks, MINOR for new knowledge/skills, PATCH for fixes).
• How consumers pin a release by targeting refs/tags/vX.Y.Z instead of main, noting that references[] already carries the commit sha for exact provenance.
• A three-step release checklist (bump the two JSON files, tag, publish).

Docs-only change; no schema, tooling, or CI changes.

[JesperSchulz]

Closing in favor of #88, which introduces the actual versioning mechanism. #88 uses a single monotonic integer (VERSION + manual release workflow) to satisfy a concrete downstream requirement: the BC-ALAgents review engine embeds the BCQuality version as the 3rd segment of its own tag and needs a stable integer. That constraint should drive the scheme, so this docs-only semver PR would document a model the repo won't actually use. Happy to follow up with a README section matching #88's scheme once it lands.