Summary

On a sharded cluster with the v2 change stream reader (featureFlagChangeStreamPreciseShardTargeting and featureFlagChangeStreamReaderV2 enabled), an idle `getMore` can return a `postBatchResumeToken` that is the resume token of a `namespacePlacementChanged` control event, from which we can't resume.

Observed errors

Cluster-level stream

```

code 280 ChangeStreamFatalError: cannot resume stream; the resume token was not found
Collection-level stream (reproduced by the new FSM reader):
```

```
code 260 InvalidResumeToken: Attempted to resume a single-collection stream, but the resume token does not include a UUID
_changeStreamVersion: "v2"
```

Both are the same leaked token. The collection-level UUID check trips first because the control event token carries no collection UUID. A cluster or database stream skips that check and reaches EnsureResumeTokenPresent, which raises 280.

Why existing tests missed it

No test resumed from a PBRT. Fetch-one-and-resume and continuous readers resume from delivered event _ids. The prefix test resumes from oplog cluster times, which are high-water-mark tokens and always valid.

This change

Adds a `fetchOneAndResumeFromPbrt` reading mode to the FSM change stream reader. After each event it issues up to three more getMores and, on an empty batch, resumes from that batch's PBRT instead of the last event token, matching driver behaviour. verifyFetchAndResume runs it as a third reader compared against the continuous reader.

Reproduction

```
buildscripts/resmoke.py run --suites=change_streams_sharding_fsm_watch_collection \
--runAllFeatureFlagTests \
--additionalFeatureFlags featureFlagChangeStreamReaderV2,featureFlagChangeStreamPreciseShardTargeting \
--mongosSetParameters "{logComponentVerbosity: {query: 3}}" \
jstests/change_stream_fsm/test_change_stream_sharding_fsm_fetch_and_resume.js
```