[Dev] Enable dense routing maps for Flex dispatch

[harryzhou2000]

• I, the PR author, have personally reviewed every line of this PR.

What does this PR do ?

Enable MCore Flex dispatchers to consume Transformer Engine's direct dense top-k routing indices whenever the selected backend requires dense metadata and the installed TE exposes the optional topk_indices output buffer.

DeepEP v1, DeepEP v2, and NCCL-EP now request int64 [num_tokens, topk] indices automatically. HybridEP now uses moe_hybridep_routing_map_mode, which defaults to "indices"; set it to "bool" to force the boolean map. Index mode uses int16 only when the installed backend reports dense-routing support and falls back to bool above the int16 expert limit or when support is unavailable. Non-Flex dispatchers and older TE combinations preserve the bool router-output path, and dispatcher compatibility paths reconstruct indices when a dense consumer requires them.

The dispatcher managers accept both representations, so direct TE output avoids reconstructing indices with torch.topk while compatibility paths remain intact. Dense padding routes remain -1, expert-TP expansion preserves invalid routes, and expert-bias counts are accumulated from the selected indices.

Companion main PR: #6615.

Testing

• Checkpoint argument restoration: 2 passed ("bool" is restored; a missing legacy field keeps "indices").
• Focused router, routing-map, dispatcher-metadata, padding, and feature-detection coverage: 27 passed.
• Real HybridEP EP=8 forward/backward passed for both moe_hybridep_routing_map_mode="bool" and "indices" using upstream HybridEP. The indices case validates the direct dense int16 [num_tokens, topk] path from TE through MCore into HybridEP.
• Dense expert-bias accounting passed in deterministic and non-deterministic modes, including fused dense routing.
• git diff --check, Ruff, and py_compile passed. All five commits have SSH signatures and Signed-off-by trailers.

Real DeepEP v1, DeepEP v2, and NCCL-EP transport were not rerun in this validation. Their dense representation selection and compatibility-manager paths remain covered by focused tests.

Issue tracking

For PRs from open-source community contributors:

• New features: a linked issue is required. Please open a feature request and reference it here before submitting the PR.
• Small updates (bug fixes, minor improvements): a linked issue is recommended and will accelerate the PR review process.

Linked issue: N/A

Contribution process

Pre-checks

• I have added relevant unit tests
• I have added relevant functional tests
• I have added proper typing to my code Typing guidelines
• I have added relevant documentation
• I have run the autoformatter.sh on my PR

Code review

Feel free to message or comment @NVIDIA/mcore-oncall to help accelerate your merge into main. The less complex your PR is, the faster it will be approved and merged!

All PRs start as draft. If you open a non-draft PR, it will be automatically converted to draft.

Step 1: Mark PR as "Ready for Review"

1. When your PR is ready, click Ready for Review.
2. An oncall reviewer is auto-assigned and expert reviewers are notified based on your changes.
   • Some PRs may jump straight to step 2. This is determined by .github/CODEOWNERS.

⚠️ Only mark as ready once merge-conflicts are resolved and the CI is passing.
Final Review might get declined if these requirements are not fulfilled.

Step 2: Final Review

For PRs that change megatron/core, once all expert reviewers have approved, the Final Review label is applied automatically and final reviewers are assigned.

For PRs outside megatron/core, this step is skipped.

Step 3: Approved

Once all required reviewers have approved, the Approved label is applied automatically.

Merge

Any member of mcore-engineers will be able to merge your PR.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.