[Pytorch] Enable TE Sequential Op to consume extra_outputs from a previously run Op

[vthumbe1503]

Description

Please include a brief summary of the changes, relevant motivation and context.

Fixes # (issue)

Type of change

• Documentation change (change only to the documentation, either a fix or a new content)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Infra/Build change
• Code refactoring

Changes

Please list the changes introduced in this PR:

• Change A
• Change B

Checklist:

• I have read and followed the contributing guidelines
• The functionality is complete
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[greptile-apps]

Greptile Summary

The PR adds named internal extra-tensor channels to PyTorch fusible operations, including forward routing, backward gradient accumulation, validation, documentation, and tests. The stale-routing fix now makes channel bindings immutable after fuser construction, but its lock also applies to temporary fusers used for standalone operation calls.

• Adds producer-to-consumer channel resolution with fan-out support.
• Keeps unbound extra tensors in the public Sequential interface.
• Routes and accumulates internal channel gradients during backward.
• Adds channel validation, mutation locking, tests, and usage documentation.

Confidence Score: 4/5

The PR should not merge until standalone BasicOperation execution stops permanently preventing later channel configuration.

A direct BasicOperation call creates and discards a temporary fuser, but construction irreversibly locks the operation, causing later public channel setters to fail even though no retained routing snapshot exists.

Files Needing Attention: transformer_engine/pytorch/ops/fuser.py and transformer_engine/pytorch/ops/op.py

Important Files Changed

Filename	Overview
transformer_engine/pytorch/ops/fuser.py	Adds internal channel routing and gradient propagation, but permanently locks operations even when the fuser is temporary.
transformer_engine/pytorch/ops/op.py	Adds the public channel-binding API and irreversible mutation guard used by both persistent and transient fusers.
transformer_engine/pytorch/ops/basic/grouped_linear.py	Initializes the conditional extra-input count before BasicOperation sizes its channel metadata.
tests/pytorch/test_fusible_ops.py	Adds broad channel routing and gradient coverage but does not cover configuring an operation after a standalone call.
docs/examples/op_fuser/op_fuser.rst	Documents channel topology, public versus internal slots, fan-out, fuser boundaries, and fused-operation responsibilities.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A["BasicOperation.forward()"] --> B["Temporary OperationFuser"]
  B --> C["Capture channel routing"]
  C --> D["Permanently lock BasicOperation"]
  D --> E["Run operation and discard fuser"]
  E --> F["Later channel setter"]
  F --> G["RuntimeError"]

Loading

_{Reviews (2): Last reviewed commit: "address review comment" | Re-trigger Greptile}

[greptile-apps]

Transient fusers permanently lock channels

When a BasicOperation is executed directly before its channels are configured, BasicOperation.forward creates and discards a temporary OperationFuser, but this constructor permanently locks the operation. A later set_extra_input_channel or set_extra_output_channel call therefore raises RuntimeError even though no retained fuser depends on the captured routing.

Knowledge Base Used: PyTorch Fusible-Operation Framework