docs(downgrader): note validators that reject 1.0 for an integer under 3.0 rules

packages/downgrader/README.md

@@ -308,6 +308,7 @@ Accepts the default OAS dialect, which adds `discriminator`, `xml`, `externalDoc
 - progenitor, which reads 3.0 only, makes an `anyOf` with two branches that take strings a struct of optional members flattened into it, which takes only objects. It reads the `"null"` branch's `type: "string"` as such a branch, so a nullable union with a string branch takes only objects where it stays an `anyOf`: where a `$ref` points to it, or where two of its branches share a type. A tuple of two kinds of string also becomes such an `anyOf` in `items`.
 - Jane's 3.0 generator throws a `TypeError` on an `anyOf`, in a property, with an object branch that requires a property of `type: "null"` alone, such as Zod's `z.null()`, since it writes each value in that property's `enum` as a PHP string, and `null` is not one. Jane reads 3.1 too, with `jane-php/open-api-3-1`, which keeps the `"null"` type.
 - kin-openapi (and Tyk Gateway's request validation for its OpenAPI APIs, which uses a fork of it), OpenApiSpex, and Ruby's openapi_parser, which committee uses, reject null for an untyped schema such as the `{}` a nullable unknown becomes, although 3.0 lets it accept every value. 3.0 admits null by name only through `nullable`, which Redocly's recommended rules reject without a `type`.
+- Python's openapi-schema-validator, which openapi-core uses, and jsonschema-rs with draft 4 rules reject a number with a zero fraction, such as `1.0`, for `type: "integer"`, as 3.0.3 defined an integer. 3.0.4, which the output names, counts it as one, as 3.1 does, and so do their 3.1 rules.
 - Microcks 1.15 turns `nullable` into a `null` type in its OpenAPI schema tests, but not for `type: "object"` or under `items`, `additionalProperties` or `not`. So a nullable object, such as Zod's `z.object({ a: z.string() }).nullable()`, rejects null there, and so does a nullable array item or map value, such as Zod's `z.array(z.string().nullable())`, or any nullable schema written inline inside one. Microcks reads 3.1 too, which keeps null.
 - MockServer 9.2 checks the schemas of an OpenAPI document, in the request matchers it builds from it and in its request and response checks, with draft 7 rules that ignore `nullable`. It turns 3.1's `type: [t, "null"]` into `nullable: true` first, so a plain nullable type rejects null in both versions, but 3.1's `{ type: "null" }` becomes an empty schema there, which takes any value, while 3.0's `"null"` branch takes none. So a nullable `$ref`, enum or union, such as Zod's `z.enum(["a", "b"]).nullable()`, rejects null only in 3.0, and a property of `type: "null"` alone, such as Zod's `z.null()`, rejects every value.
 - Amazon API Gateway's REST APIs, which import 2.0 and 3.0 only, check request bodies against JSON Schema draft 4 models and do not support `nullable`, so with request validation on, `nullable: true` lets no null through there, and the `"null"` branch takes no value at all. A property of `type: "null"` alone, such as Zod's `z.null()`, then fails every request that holds it.