Adding GPT OSS Support

[Maxusmusti]

Adds support for GPT OSS:

• trains de-quantized
• re-quantizes at save
• freezes routing parameters (currently), but also has support for aux loss

Also cleans up our loss calculation by removing our forward override and using accurate batch stats

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. @Maxusmusti please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[RobotSail]

Great work on the GPT-OSS integration! The MXFP4 quantization/dequantization implementation, router parameter freezing, auxiliary loss support, and batch collation refactor represent solid technical execution.

Before we can merge this PR, there are several issues we need to address:

1. Data processing seems like it may have trouble correctly identifying GPT-OSS models in edge cases
2. The batch collator looks like it could be dropping minibatches and not accumulating sample/token counts correctly
3. kernels dependency is missing from requirements
4. In the training loop, looks like we're reducing floats instead of ints in several places
5. Quite a few functions and variables could use more descriptive names
6. I noticed several places where our logic can be simplified, especially in the GPT-OSS model saving workflow

I like the batch collator refactor, but I'm worried that using a running estimate for batch_num_loss_counted_tokens may cause problems. Since we're now using a running estimate for the total number of loss counted tokens in the entire minibatch, the gradient
signal the model receives will be biased toward the first few microbatches, which can heavily overshoot or undershoot the estimate compared to later microbatches. This could be a big problem when training with large EBS (3840) and on datasets with rare
samples you want to train on (~10k/370k).

We may want to add code in the future that reads the number of loss counted tokens in each batch (validation loss, logging, etc.). In these cases, the value won't be stable until we hit the number of accumulation steps.

One way to solve this issue, while also fixing the dual-use of regular and batch sampler during distributed sampler fallback, would be updating how we use the MultipackSampler to have it behave like a regular sampler that generates samples ahead of time on a
budget, then collates them together at the end. This way, each time you get a batch from the data loader, you know which tokens will be loaded.

It would also be good to add some behavior-driven tests for the sampling so we can have confidence in the refactor.

Please address the issues listed above and consider the suggested approach for the batch collator. The core implementation is solid - these changes will make it production-ready.

[RobotSail]

In what cases would this raise an exception? Afaik, tokenizer.encode will encode any string into a set of tokens.

[RobotSail]

LGTM