Define the 1.x compatibility policy for catalog, behavior, and output changes

[e54-bot]

Parent: #252

Readiness: needs-decision (see "Open decision")

Problem

docs/compatibility-facades.md and docs/release.md define Rust API compatibility only. Recent releases also changed catalog content (#299) and parse/emit output (#300, #303). cargo-semver-checks cannot see those changes, and no document says how they are versioned under 1.x. Consumers using a caret requirement pick up minor releases on cargo update, so they need to know what a minor release may change.

Maintainer direction:

• The catalog follows Overwatch's update cadence, most likely per season, and those updates ship as minor releases.
• Non-major breaking changes do not bump the major version.
• Major releases are reserved for Rust API breaks.

Proposed policy

• Major: a Rust API incompatibility in the documented public API, as determined by cargo-semver-checks.
• Minor:
  • catalog updates: added, removed, or re-parameterized action/value ids, heroes, maps, and settings;
  • parse, validation, or emit changes that align output with the live client (the fix(parser)!: preserve contextual literal substitutions #300 and fix(emitter)!: emit constant wrappers and yes/no settings the way the client accepts them #303 kind);
  • new public API;
  • MSRV increases.
• Patch: fixes with no observable change to the parsed Program, emitted text, validation results, or catalog.
• catalog_version (CatalogIdentity) is versioned independently of the crate version.
• Release notes list catalog changes and behavior/output changes separately from API changes, so caret-pinned consumers can find them.

Open decision

When Overwatch removes a Workshop action or value, what does workshop-rs do?

• Reject: the parser rejects the id from then on, matching the live client.
• Legacy id: the parser keeps accepting the id so older projects still parse, while emit and validation mark it as removed.

The same question applies to corrections of ids that were never native, like #299.

Scope

• Record the policy, including the decided removal behavior, in docs/compatibility-facades.md.
• Link it from the semver section of docs/release.md.
• Make catalog and behavior changes identifiable in release notes. The mechanism is open, for example a conventional-commit scope or a changelog section.

Non-goals

• A new compatibility framework, stability database, or release process.
• Changing the cargo-semver-checks gate logic. After Freeze the workshop-rs public API for 1.0 #252's other API changes, catalog and behavior changes no longer touch the Rust API shape.

Acceptance criteria

• docs/compatibility-facades.md states the major/minor/patch rules above, including the decided behavior for ids that Overwatch removes.
• docs/release.md references the policy.
• The release-note mechanism for catalog and behavior changes is documented, and the next release uses it.
• The maintainer reviews and approves the wording. This is a documentation change, so review is the completion check.

Dependencies / ownership

• Owner: workshop-rs.
• Depends on the maintainer's decision on removed ids.
• Relies on Remove catalog-generated typed constructors from the public API before 1.0 #311 (typed constructors) and Mark growing public structs, error enums, and settings domains #[non_exhaustive] before 1.0 #312 (#[non_exhaustive]). Without them, catalog changes stay Rust API changes.

[e54-bot]

Decision (maintainer): no legacy ids. Never-native id corrections (#299 kind) ship as minor releases and the parser rejects the removed id. Overwatch has never removed a native Workshop action or value; if it ever does, the release notes declare it a breaking behavior change and the maintainer decides then between minor and major. Release notes are identified by PR title: feat(catalog) for catalog updates, feat(<area>) plus a ## Behavior change section for parse/validation/emit changes, fix only for patch-level changes. Implemented in #321.