Fix linear bias broadcasting in the Dynamo converter

[fs-eire]

Description

This change fixes linear bias broadcasting for higher-rank inputs in the Dynamo converter.

Previously, the aten.linear converter passed a rank-1 bias directly to the generic elementwise-add converter. For static shapes, that path broadcast the bias to the full output shape—for example, [O] to [B, S, O]—before creating the TensorRT elementwise add.

This change rank-aligns the operands first, preserving singleton dimensions—for example, [O] to [1, 1, O] for a [B, S, O] linear output—and lets TensorRT perform the elementwise broadcast. This avoids unnecessary bias materialization and gives TensorRT/Myelin more opportunities to canonicalize and fuse related linear operations.

The issue was identified while comparing ONNX-TensorRT and Torch-TensorRT AOT plans for the black-forest-labs/FLUX.1-schnell text encoder. Before this change, the three Q/K/V projections were combined into a token-major [1, 77, 2304] output, with their biases and layout transformations handled downstream. This produced three additional AddReshTranReshMove materializations per transformer block.

With this change, TensorRT recognizes a projection-major QKV operation with:

• Weights: [3, 768, 768]
• Biases: [3, 1, 768]
• Output: [3, 77, 768]

For the 12-block FLUX text encoder, this eliminates all 36 QKV AddReshTranReshMove materializations. In an isolated patch-only benchmark on B200 with TensorRT 11.3.0.1, BF16, and batch size 1, Torch-TensorRT AOT latency improved from 0.5284 ms to 0.5144 ms.

A rank-3 aten.linear test with bias is included to cover the corrected broadcasting behavior.

No new dependencies are required, and there are no public API changes.

Additional attention-layout and mask optimizations are separate issues and are intentionally outside the scope of this change.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified

[narendasan]

LGTM

[zewenli98]

LGTM