What?

Makes core/content-query read its id input and its author and parent filters the way the input schema validates integers.

Why?

The input schema declares these as integers, and the JSON Schema integer type accepts whole floats and numeric strings such as "12.0" or "+12". The execute side read them differently:

• The author and parent filters accepted only native integers and digit strings, so {"author": "12.0"} passed validation and then failed with content_invalid_filter.
• The id went through absint(). A whole float beyond the integer range passes validation, and the cast wraps it around, so an ID of 2^64 + 4194304 read post 4194304. The permission check resolved the same post, so read permissions still applied, but the ability returned a post the caller did not ask for. In a direct call to the execute callback, a non-numeric ID became 0, and get_post( 0 ) falls back to the global post.

This came up in the review of #1025, whose write abilities parse their IDs with the same helper. That PR leaves the read ability as it is, so the change lands here.

How?

• parse_filter_int() accepts a value when rest_is_integer() does, as schema validation does, and rejects a float at or beyond PHP_INT_MAX before casting it.
• check_permission() and execute_content_query() parse the id with it, and skip the lookup when the ID is invalid.

Testing Instructions

Run the content ability tests:

npm run test:php -- --filter ContentTest

Both new tests fail on develop:

• test_author_filter_accepts_every_integer_form fails with "An author filter given as a whole float should be honored."
• test_get_by_id_beyond_the_integer_range_is_denied fails with "An ID beyond the integer range should not resolve a post.", because the lookup returns post 4194304.

Changelog Entry

Fixed - The content query ability accepts every integer form its schema allows for the author and parent filters, and no longer resolves an ID beyond the integer range to another post.