Fix non-idempotent revert_weight_conversion corrupting trust_remote_code saves
Author: Bluear7878
Pull request: yes

# What does this PR do?

Fixes #46650

`save_pretrained` silently corrupts the checkpoint of a `trust_remote_code` model whose `model_type` has a
hardcoded conversion mapping in `conversion_mapping.py` (currently `nomic_bert` and `jina_embeddings_v3`).

A remote model is loaded by its own remote modeling code, which builds the state dict directly and never
runs the core conversion engine, so `model._weight_conversions is None` and its in-memory keys are already
in the **original on-disk layout**. On save, `revert_weight_conversion` (`core_model_loading.py`) fabricates
the mapping from the hardcoded table and applies its **reverse** anyway. For an unanchored `WeightRenaming`
whose target is a substring of its source — e.g. `nomic_bert` / `jina_embeddings_v3`
`WeightRenaming("encoder.layers", "layers")` — reverting keys that already carry the prefix double-prepends
it:

```python
from transformers.core_model_loading import WeightRenaming

rev = WeightRenaming(r"encoder.layers", r"layers").reverse_transform()
print(rev.rename_source_key("encoder.layers.0.attn.out_proj.weight")[0])
# -> 'encoder.encoder.layers.0.attn.out_proj.weight'   (expected: unchanged)
```

End-to-end, `AutoModel.from_pretrained("nomic-ai/nomic-embed-text-v1", trust_remote_code=True)`
→ `save_pretrained(d)` → `from_pretrained(d, trust_remote_code=True)` reports every `encoder.layers.*` weight
as missing and silently keeps the randomly-initialised weights — accuracy collapses, with no error raised.

## Fix

The fabricated mapping only ever applies to a model whose in-memory keys are in the **canonical (native)**
layout. That is never the case for a `trust_remote_code` model — its keys are already on-disk. So skip the
fabricated revert when the model class lives in the dynamic `transformers_modules` namespace, and revert
native models (built via `from_config`, whose keys are canonical) exactly as before.

Alternatives considered and ruled out:
- **Detecting "keys already on disk" per-key** (does the forward mapping still rename a key?): false-positives
  on native models whose canonical keys still match an unanchored forward rename — it wrongly skipped their
  legitimate revert and broke `test_reverse_loading_mapping` for ~10 models. The canonical-vs-disk question
  is undecidable per-key for the `X.model -> X` mapping family.
- **Anchoring each affected mapping** (`^encoder\.layers`): only patches one model and breaks the `nomic_bert`
  wrapper classes (`base_model_prefix` nesting under `nomic_bert.`) on both load and save.
- **Migrating these mappings to `PrefixChange`** (à la #45567): does not address the unanchored reverse rename
  and still requires per-model migration.

## Tests

`tests/utils/test_core_model_loading.py::TestRevertWeightConversionRemoteCode`:
- a `trust_remote_code` model (class in `transformers_modules`) with on-disk-layout keys is saved unchanged
  (no `encoder.encoder.*`),
- a native model (built via `from_config`) with canonical keys still round-trips to the on-disk layout.

The full `test_reverse_loading_mapping` suite (which builds native models) is unchanged by this fix. `ruff
check` + `ruff format` clean.

## Code Agent Policy

- [ ] I confirm that this is not a pure code agent PR.

## Before submitting

- [ ] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request)?
- [ ] Was this discussed/approved via a Github issue? — #46650
- [ ] Did you write any new necessary tests? — `TestRevertWeightConversionRemoteCode`

## Who can review?

@Cyrilvallez — this directly extends your #45567 (`PrefixChange` filter in `revert_weight_conversion`).


Comments:
**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46651)

@Cyrilvallez this fixes a silent `save_pretrained` corruption for `trust_remote_code` models (`nomic_bert` / `jina_embeddings_v3`) — it directly extends your #45567. Would you be able to take a look when you get a chance? CircleCI is green; the `pr-ci` reds are a self-hosted-runner infra failure (0 actual test failures).

Thanks for the PR! The proper fix is in https://github.com/huggingface/transformers/pull/46876 though! Let me know if something is unclear