GetReadOnlyProvider(providers) without allowFallbackToReadWrite null-crashes on single-datasource deployments (4 remaining call sites)

`GetReadOnlyProvider(providers)` returns `null` when no dedicated Read-Only datasource is configured and `allowFallbackToReadWrite` is not passed — and most deployments (including the standard dev setup) run a single read-write datasource. Any resolver that calls it bare then null-derefs on first use, e.g. `SearchEntitiesResolver` crashed every `SearchEntities` query with `Cannot read properties of null (reading 'SearchEntities')`.

PR #3296 fixes `SearchEntitiesResolver` (it was breaking IT52 over client transport). The same latent bug remains at:

- `packages/MJServer/src/resolvers/PotentialDuplicateRecordResolver.ts:77`
- `packages/MJServer/src/resolvers/MergeRecordsResolver.ts:30`
- `packages/MJServer/src/resolvers/MergeRecordsResolver.ts:66`
- `packages/MJServer/src/resolvers/ActionResolver.ts:412`

Each is a read workload where falling back to the read-write provider is safe: add `{ allowFallbackToReadWrite: true }` (or make the helper's null return impossible and force callers to choose explicitly).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start with the four listed call sites in PotentialDuplicateRecordResolver.ts, MergeRecordsResolver.ts, and ActionResolver.ts, then compare the existing SearchEntitiesResolver fix in PR #3296. Confirm each read workload handles a single read-write datasource without a null provider, and verify the affected resolver paths no longer null-dereference.

Written by the indexing model from the issue text.