Fix silent weight re-initialization for custom PreTrainedModel subclasses
Author: iamsharduld
Pull request: yes

## What does this PR do?

Fixes #46620.

`from_pretrained` silently returned a **randomly-initialized** model — with a clean `loading_info` (`missing_keys`/`unexpected_keys`/`mismatched_keys` empty, no warning) — for custom out-of-tree `PreTrainedModel` subclasses whose `_init_weights` writes parameters in-place (e.g. `module.weight.data.normal_(...)`). The weights were loaded correctly from the checkpoint and then overwritten by `_init_weights` *after* loading.

### Root cause

During loading, `set_param_for_module` materializes each param from the checkpoint and flags it `_is_hf_initialized = True`. `_initialize_missing_keys` → `initialize_weights()` → `_initialize_weights(module)` then runs.

`_initialize_weights` has a param-level backstop: skip a module when its directly-owned params/buffers are already `_is_hf_initialized`. But that backstop was gated behind `is_remote_code`. A custom subclass loaded directly (not via `trust_remote_code`) has `is_remote_code() == False`, so the backstop was skipped and `self._init_weights(module)` ran, overwriting the freshly-loaded weights in place.

In-tree models are unaffected by the *bug* because their `_init_weights` go through the guarded `torch.init` / `transformers.initialization` helpers, which check `_is_hf_initialized` per tensor. A user writing `weight.data.normal_(...)` operates on `.data` (a distinct tensor without the flag), so it isn't protected — exactly the scenario this backstop was added for, but it was limited to remote code.

### Fix

Apply the backstop to **all** models, but only skip a module that **directly owns** params/buffers (with all of them already initialized). A module that owns none — its params live in child modules — may still initialize those children via *parent dispatch* in `_init_weights` (e.g. a `T5`-style attention block initializes its `q`/`k`/`v`/`o` projections), so it must keep running `_init_weights`. Dropping the `is_remote_code` gate *without* this guard would skip such parent modules and leave their children uninitialized (an empty `all(...)` over no owned tensors is `True`).

The `is_remote_code` parameter is kept on the signature because `_initialize_weights` is used as a callback (`fn(module, is_remote_code)`) by both `smart_apply` and the DeepSpeed ZeRO-3 path (`initialize_weights_zero3`); it is simply no longer consulted by the gate.

In-tree models are otherwise unaffected: their `_init_weights` go through the guarded helpers, so skipping a fully-loaded module is equivalent to running them.

### Tests

Added `test_from_pretrained_does_not_reinit_custom_model_weights`: a save→load round-trip on a minimal custom `PreTrainedModel` with an in-place `_init_weights`, asserting the loaded weights survive and `loading_info` is clean. The test **fails on `main` and passes with this change**.

Verified locally (transformers `5.13.0.dev0`, torch `2.12.0+cpu`):
- the issue's exact repro now reports the saved weight mean (`0.5`) instead of `~0.0007`;
- the new regression test passes (and fails without the fix);
- the parent-dispatch path is covered: `test_can_init_all_missing_weights` passes for a `T5`-family model (UDOP), along with its `test_save_load`;
- related load / init / tied-weight tests in `tests/utils/test_modeling_utils.py`, plus Llama/T5 `test_save_load`, still pass.

## Before submitting
- [x] This PR fixes a bug (link to issue: #46620).
- [x] Did you write any new necessary tests?

## Who can review?

Anyone, but the modeling/loading area is owned by @Cyrilvallez and @SunMarc.


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=46632)

See my answer on the linked issue!