An int field accepts values past Int32, and deciding what int means is the real work

Split out of #648 so that issue can ship in 4.0.2.

#648 groups six cases that all return 500 on malformed input. Five of them are pure defects: the
request fails today and will still fail after the fix, only with a 4xx and without a Postgres error
code in the body. Those stay on 4.0.2.

This one is different. A field typed `int` accepts `99999999999999` today and stores it verbatim,
because `FieldTypeRegistry.IsInteger` accepts any CLR long. Capping it to the Int32 range rejects a
request the API accepts right now, which section 6 of CLAUDE.md counts as a breaking change to the
HTTP surface. It moves `ApiContract.Version`, so it cannot go in a patch: barakoBrew pins
`SUPPORTED_CONTRACT = { min: 1, max: 1 }` and stops the console on `api-newer`.

There is also a decision to make rather than just a bound to add. Either:

- `int` means Int32, the value is rejected with a 400, and anything already stored outside the range
needs a migration story, or
- `int` means Int64, the registry is right, and the documentation and the OpenAPI schema are what
need fixing.

The second is cheaper and breaks nothing, but it makes the field name misleading for anyone who
reads `int` as 32 bits. Decide which before writing the guard.

Done when: the meaning of `int` is written down in the field-type docs, the registry matches it, and
a test covers the boundary in whichever direction was chosen.

Start with section 6 of CLAUDE.md, then inspect FieldTypeRegistry.IsInteger, the field-type documentation, and the OpenAPI schema. Review the compatibility implications described for ApiContract.Version and the barakoBrew supported contract. Done means the meaning of int is decided and documented, the registry and schema match it, and a boundary test covers the chosen behavior.

Written by the indexing model from the issue text.