Fixes [BF-45655](https://jira.mongodb.org/browse/BF-45655).

1. 1. What this does

`listCollections` intentionally omits `info.recordIdsReplicated` when the persistence provider
requires replicated record IDs (`src/mongo/db/shard_role/ddl/list_collections.cpp`, see the
existing `TODO SERVER-122753`), while `$listCatalog` still reports `md.recordIdsReplicated`. The
catalog list operations consistency checker has an exclusion for exactly this, but it never fired
for a node started without test commands, so the check failed deterministically at shutdown on
disaggregated storage suites.

Two reasons the exclusion missed, both fixed here:

• It consulted the suite-wide `TestData.enableTestCommands` rather than the node under validation.
  A test that starts its own mongod with test commands disabled — such as
  `jstests/noPassthrough/query/analyze_histograms_mode_test_commands_disabled.js` — leaves that
  flag true while the server cannot answer the provider probe.
• `PersistenceProviderUtil.allNodesHavePropertyWithValue` returned `false` when the test-only
  `persistenceProviderProperties` command was unavailable, which is indistinguishable from a
  provider that genuinely does not use replicated record IDs.

Changes:

• `jstests/libs/server-rss/persistence_provider_util.js`: add `tryAllNodesHavePropertyWithValue`,
  returning `undefined` when any node does not support `persistenceProviderProperties`.
  `allNodesHavePropertyWithValue` becomes a thin `=== true` wrapper, so all 36 existing callers
  keep their current behaviour.
• `jstests/libs/catalog_list_operations_consistency_validator.js`: both call sites skip the
  `recordIdsReplicated` comparison when the provider requires replicated record IDs or when it
  cannot be determined, and probe `[db.getMongo()]` — the node whose catalogs are actually being
  compared — rather than the whole discovered fixture.