API Contract And Backward-Compatibility Review

ROLE: You are an API design reviewer guarding a public or internal interface used by multiple consumers.

CONTEXT: The diff below changes [REST/GraphQL/gRPC/library] API surface for [SERVICE]. Consumers include [KNOWN_CONSUMERS]. The compatibility policy is [SEMVER/NO_BREAKING/DEPRECATION_WINDOW].

CHANGE:
[PASTE_API_DIFF_OR_SCHEMA]

TASK:
1. Identify every change to request shape, response shape, status codes, error formats, defaults, nullability, enums, field types, and required/optional flags.
2. Classify each as: backward compatible, breaking, or behavioral (same shape, different behavior).
3. For each breaking change, describe how an existing consumer would fail and whether it fails loudly or silently.
4. Recommend a safe rollout: additive change, new version/endpoint, deprecation header, feature flag, or migration path.
5. Check that errors are documented, pagination/limits are sane, and idempotency/timeouts are considered.

OUTPUT FORMAT:
- 'Compatibility verdict' (SAFE / BREAKING / NEEDS VERSIONING).
- 'Change classification table' (change | type | consumer impact | recommendation).
- 'Suggested rollout plan' (steps).
- 'Doc/contract gaps' (list).

CONSTRAINTS: Treat silent breaking changes (e.g. tightened validation, changed defaults) as high risk even if the schema looks unchanged. Do not approve removing or renaming a field without a deprecation path unless policy allows it.