Currently, the sharded createCollection path on a sharded cluster makes the DB primary shard call the user-facing `create` command on itself via a DBDirectClient. This effectively re-enters the replica-set-level create command implementation in the middle of executing another command.

This approach is problematic because:

• It re-runs user-facing create logic (command parsing/serialization, user-facing validation, API version checks, etc.) even though those checks have already been performed in the sharded `createCollection` path.
• It risks duplicating logic between the sharded and replica set create implementations, making it harder to reason about correctness and to maintain the code.
• It makes it harder to ensure that the sharded create path relies on a single, well-defined internal create primitive, rather than re-invoking a higher-level command entry point.

The goal of this ticket is to:

• Bypass the user-facing create command on the DB primary shard when executing a sharded `createCollection`.
• Introduce or reuse an internal createCollection helper that can be invoked directly from the sharded create path, using the already validated/serialized parameters.
• Ensure that any user-facing checks (including API version validation and other command-level checks) are run exactly once, in the outer sharded `createCollection` command, before delegating to the internal helper on the primary shard.