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:

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 Move some conversion mappings to PrefixChange #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?
• Was this discussed/approved via a Github issue? — save_pretrained corrupts keys (encoder.encoder.*) for trust_remote_code / from_config models via non-idempotent reverse rename #46650
• Did you write any new necessary tests? — TestRevertWeightConversionRemoteCode

Who can review?

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