Background

While working on CSHARP-5931 ($scoreFusion builder), I designed the three public ScoreFusion overloads such that each public overload validates its own input shape (with the correct paramName), then delegates to a private ScoreFusionCore for cross-cutting options validation and BSON rendering. Also, error messages were standardized to BCL-style phrasing (e.g. "Value cannot be an empty collection.", "Value cannot contain a null pipeline.").

$rankFusion (added in CSHARP-5478) does not follow this pattern. It has the same three-overload shape but:

• The dictionary overload does not validate that pipelines is non-empty.
• The array and tuple overloads delegate to the dictionary overload, so empty/null-entry errors surface with paramName: "pipelines" even when the caller used the array or tuple overload (the tuple overload's user-facing parameter is pipelinesWithWeights).
• The tuple overload always passes the constructed weights dictionary through, even when empty — emitting combination: { weights: { } }}} for an all-null-weight tuple input. {{$scoreFusion collapses this case to no combination block.

The aim of this ticket to refactor $rankFusion to follow the same pattern as $scoreFusion since they are similar stages.