Fix some models cache initialization
Author: albertvillanova
Pull request: yes

Fix Gemma3 cache initialization.

Current code:
```python
if use_cache and past_key_values is None and not self.training:
    past_key_values = DynamicCache(config=self.config)
```

The `not self.training` check prevents cache creation during training. However, GRPO (and similar RL trainers) call `model.generate()` during training to produce completions for scoring. This condition blocks cache creation, resulting in:
  - First forward: `past_key_values=None`, no cache → no error (prefill processes all tokens)
  - Second forward: `past_key_values=None`, `cache_position=[279]` → mask expects 280 tokens but KV has only 1 → **shape mismatch error**

This PR removes the `not self.training` condition. 
```python
if use_cache and past_key_values is None:
    past_key_values = DynamicCache(config=self.config)
```
Now, the cache flow is:
  - First forward:  `past_key_values=None` → DynamicCache(length=279)
  - Second forward: `past_key_values=DynamicCache(279)` → DynamicCache(length=280)

Related issue in TRL:
- https://github.com/huggingface/trl/issues/4593

CC: @Cyrilvallez and @vasqu, who were investigating the underlying issue

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42586). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

I will check more, but I believe the true issue comes from the line I showed in my comment https://github.com/huggingface/trl/issues/4593#issuecomment-3606035594! Here, you're only treating a symptom I think, not the full problem. Also, you said in the issue that you were not in training mode 👀

Usually, even in the middle of training, you will go back to inference mode to perform evaluation in order to deactivate dropout etc, unless I'm very mistaken

Actually I was wrong, and this is the correct fix @albertvillanova! 

@vasqu because the input preparation relies on `use_cache` and not on `cache is None` to know whether we'll have a cache or not, there was a silent bug in which the input would be sliced as if a cache was used, but due to the `is training` conditional, no cache was provided. So generation would be successful, but completely wrong, as it would just see the last token in each generation step. The change in `mask_utils` actually uncovered it, because it shown the mismatch between what the size should be and what the size actually is, because we should have a cache but don't.... Before we would just prepare a mask of size 1, which is the input size, but the input size should NOT be that.
It started being an issue since https://github.com/huggingface/transformers/pull/41505 2 months ago... Before that, the Cache would have been there anyway and no problem

@albertvillanova I'm going to push much more changes on this PR, as we should really be more careful about this!
In the future, I'm going to make sure that `generate` relies on whether we actually have a cache or not, and not on `use_cache` which can be decorrelated from the cache existence as it's the case here

> Usually, even in the middle of training, you will go back to inference mode to perform evaluation in order to deactivate dropout etc, unless I'm very mistaken

I think we are lucky here that most newer models do not use dropout so there is no real difference in inference. I agree tho, in general, the model should be set to eval `model.eval()` just to be sure.

> Here, you're only treating a symptom I think, not the full problem. Also, you said in the issue that you were not in training mode 👀

I think this really is the core issue --> We should not cut our inputs at all when we do not use a cache (as indicated by the config flag). However, the default flag is set to to `True`. This forces the cutting of the input, except you explicitly pass `use_cache=False` yourself. That shouldn't be the case at all! 

Some quick pointers what happens:
- https://github.com/huggingface/transformers/blob/75c135d76f6db226d83213c6bb658a474dddb07d/src/transformers/generation/utils.py#L616 We get `use_cache=True` here
- https://github.com/huggingface/transformers/blob/75c135d76f6db226d83213c6bb658a474dddb07d/src/transformers/generation/utils.py#L619-L625 We get into the cache-dependent input prep
- https://github.com/huggingface/transformers/blob/75c135d76f6db226d83213c6bb658a474dddb07d/src/transformers/generation/utils.py#L523 Our input gets cut (even if it shouldn't

The real solution IMO is as @Cyrilvallez said: Remove the default for `use_cache`, e.g. by removing it completely there and let it be handled within the kwargs.

Ok, but then let's do both @Cyrilvallez: This fix along the kwarg being defaulted to `True`. It's not good either way

Haha we commented at the same time

Yeah agree the kwargs should not be True, but it's not the one at fault here

Pushed the necessary change related to this PR on several models, and took the opportunity to do quite some cleanup at the same time!

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: cohere2, gemma3, gemma3n, modernbert_decoder, moshi, t5gemma2