Revisit: confirm parseShellBSON (Loose) backward compatibility with EJSON.parse for projection and sort

Context

In ClustersClient.runFindQuery / streamFindQuery and ClusterSession.getCurrentFindQueryParamsForExecution, projection and sort strings are now parsed with @mongodb-js/shell-bson-parser in ParseMode.Loose, replacing EJSON.parse.

The loose parser is a superset of strict EJSON and accepts mongosh style input such as unquoted keys and ObjectId(...). Telemetry already counts parse failures via QueryError('INVALID_PROJECTION' | 'INVALID_SORT'), so post-release regressions are observable.

This issue tracks a focused compatibility pass to confirm that strict EJSON inputs that previously parsed still produce the same runtime values.

Suggested verification

• Projection { "createdAt": { "$date": "2024-01-01T00:00:00Z" } } produces an equivalent Date.
• Sort { "_id": -1 } is unchanged.
• Nested extended JSON: { "$gt": { "$numberLong": "9007199254740992" } }.
• Empty {} strings remain short-circuited.

Definition of done

• A small fixture-driven unit test asserts equivalence between the old EJSON.parse output and the new parseShellBSON output for a representative set of strict EJSON inputs.

Start with ClustersClient.runFindQuery, streamFindQuery, and ClusterSession.getCurrentFindQueryParamsForExecution to trace projection and sort parsing. Add a fixture-driven unit test comparing EJSON.parse with parseShellBSON in Loose mode for the listed strict EJSON cases, including empty strings. Done means equivalent runtime values are asserted for representative projection, sort, date, and numberLong inputs.