Build/Test Tools: Use strict assertions in the query tests.

[haritpanchal]

What

Reviewed the 5 files claimed on the ticket under tests/phpunit/tests/query/.
8 of 24 loose assertions convert; the rest are legitimate object-identity or
opposite-direction type mismatches.

Converted:

• cacheResults.php, results.php (comment_ID cases) — $comment_id is the
  return of the test factory's wp_insert_comment(), which is (int) $wpdb->insert_id. WP_Comment::$comment_ID is documented numeric-string
  and populated raw from $wpdb->get_row(), so the expected side is cast to
  match.
• results.php — test_post_password(): WP_Query's 'fields' => 'ids'
  branch explicitly does array_map( 'intval', $this->posts ), so results are
  real ints. The test's $one variable happens to be pre-cast to (string)
  for use in post__in, which is unrelated to the result type — cast to
  (int) at the assertion site instead. Proven necessary by mutation:
  removing the cast fails with Expected: Array(0 => '38') / Actual: Array(0 => 38).
• setupPostdata.php — the one comparison against strip_ws( $content )
  converts directly to assertNotSame(); both sides are plain strings.

Left as assertEquals()/assertNotEquals(), no changes:

• isTerm.php (10) — every case compares a fresh get_queried_object() or
  get_term() call against a term object obtained earlier in the same test.
  Proven by mutation: converting one to assertSame() fails with Failed asserting that two variables reference the same object. — a pure identity
  mismatch, since two independent term fetches never share the same instance.
• generatePostdata.php (1), setupPostdata.php (4) — same identity pattern
  with WP_User: a factory-created user vs. a separate get_userdata() call
  inside WP_Query::generate_postdata().
• cacheResults.php (1) — already carries its own comment explaining exactly
  why it must stay assertNotEquals() rather than assertNotSame(): the test
  needs to ignore object instance IDs and only compare by value.

Testing

npm run test:php -- --group query
1896 tests, 4436 assertions, 0 failures

node ./tools/local-env/scripts/docker.js run --rm php ./vendor/bin/phpunit -c tests/phpunit/multisite.xml --group query
1896 tests, 4436 assertions, 0 failures

PHPCS clean on all 3 changed files. Test-only change; no production code touched.

Trac ticket: https://core.trac.wordpress.org/ticket/64895

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Helping locate candidate files and cross-check each expected literal
against the return-type contract. I reviewed the conversions myself.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props haritpanchal.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[haritpanchal]

The 3 failing jobs (PHP 8.3 / MySQL 8.4 multisite with memcached, PHP 8.3 / MySQL 8.4 with memcached, and PHP 8.5 / MySQL 5.7) appear to be a known infrastructure issue and are not related to this diff.

All three jobs hang immediately after the frontend asset build and are terminated by the runner’s 5-minute build timeout: The action 'Build WordPress' has timed out after 5 minutes.

I confirmed the same failure pattern on unrelated PRs as well (e.g. #13601).

All substantive checks are passing, including Coding Standards, PHPStan, and the remaining ~90 PHP/DB matrix combinations.