[CI/Build] Conditionally register cutlass_fp4_group_mm to fix building on Hopper

[mgoin]

Purpose

cutlass_fp4_group_mm was unconditionally registered in torch_bindings.cpp even though its implementation is only compiled when ENABLE_NVFP4_SM100 is defined, causing undefined symbol errors on Hopper.
This fix moves the ops.impl registration to be conditionally compiled within nvfp4_blockwise_moe_kernel.cu using TORCH_LIBRARY_IMPL_EXPAND, matching the pattern used by other conditionally-compiled operations like cutlass_blockwise_scaled_grouped_mm.

Test Plan

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request correctly resolves a build issue on Hopper systems by conditionally registering the cutlass_fp4_group_mm operator. Moving the implementation registration into the same compilation unit (nvfp4_blockwise_moe_kernel.cu) as the function definition ensures that the operator is only registered when it is actually compiled, thus preventing linker errors. The approach is consistent with how other conditionally compiled operators are handled in the codebase. The changes are clean, targeted, and effectively address the problem.