Surfaced while reviewing the walker migration in #949.

What's missing

check_request_property_pattern_added_or_changed.go and check_response_pattern_added_or_changed.go only emit property-level changes:

• request-property-pattern-removed
• request-property-pattern-added
• request-property-pattern-changed
• request-property-pattern-generalized

(and the response equivalents)

There are no body-level counterparts (request-body-pattern-* / response-body-pattern-*) — the constants don't exist, and the checker never inspects mediaTypeDiff.SchemaDiff.PatternDiff at the body level.

When this matters

OpenAPI lets the top-level request or response body be a string-typed schema with a pattern field, e.g.:

requestBody:
  content:
    text/plain:
      schema:
        type: string
        pattern: "^[a-z]+$"

If the pattern changes (^[a-z]+$ → ^[A-Z]+$), that's a breaking change for clients sending payloads matching the old pattern. Today's checker doesn't notice — oasdiff breaking returns clean for that change.

How common is it

Probably rare. Top-level string-typed bodies are unusual in REST APIs; the common case is the body schema has properties, which the property-level checker handles correctly. But the gap is real and an asymmetry vs every other body+property pair (anyOf / oneOf / allOf / nullable / type / min / max / dependent_schemas / prefix_items / etc all check both levels).

Fix shape

Mirrors the body-level pairs in the other recently-migrated checkers. Concretely:

1. Add four constants in each file (RequestBodyPatternRemovedId etc).
2. In the walker callback, emit at body level when info.schemaDiff.PatternDiff != nil, following the same four-case split (removed / added / changed / generalized) the property branch already does.
3. Add localized messages in checker/localizations_src/ for all four locales (en, es, pt-br, ru).
4. Tests using a top-level string body fixture.

Estimated: ~80 lines per side plus a couple of test fixtures. Probably half a day end-to-end with localisation.

Low priority — anyone who has top-level string-typed bodies in their spec, please add a 👍.