feat(torch): add GMS weight-loading prototype

[galletas1712]

Summary

• extract only the GMS pieces from PR [TRTLLM-11851][feat] MX and GMS integration MVP for Dynamo weight sharing NVIDIA/TensorRT-LLM#13045 into a fresh TRT-LLM branch
• intentionally exclude all MX-related code, config, and tests
• adapt the TRT-LLM side to the new explicit Dynamo/GMS two-step API:
  • register_module_tensors(...)
  • finalize-only finalize_gms_write(...)
• add a minimal LoadFormat.GMS weight-loading path plus focused GMS-only tests

Scope in this PR

Included:

• tensorrt_llm/_torch/memory/gpu_memory_backend.py
• tensorrt_llm/_torch/memory/__init__.py
• LoadFormat.GMS and GMS args in tensorrt_llm/llmapi/llm_args.py
• GMS RW/RO load path in tensorrt_llm/_torch/pyexecutor/model_loader.py
• minimal Linear._weights_presharded support for RO materialization
• GMS-only unit coverage and API stability snapshot updates

Intentionally excluded:

• all MX pieces from PR [TRTLLM-11851][feat] MX and GMS integration MVP for Dynamo weight sharing NVIDIA/TensorRT-LLM#13045
• MX checkpoint loaders / config / validators / tests
• unrelated async / executor / visual-gen / workflow changes from that donor PR

API target

This branch targets the new explicit Dynamo/GMS split API. On the TRT-LLM side the write path now does:

1. register_module_tensors(...)
2. torch.cuda.synchronize()
3. finalize-only finalize_gms_write(...)

Deferred parity items

Still deferred from the broader single-node/failover line:

• SleepConfig.restore_modes pickling fix
• TP>1 GMS autotuner disable/guard
• spec-dec / shared-draft RO alias-prebind parity

Notes

• This draft PR is intended for review of the GMS-only extraction shape first.
• The branch is currently based on the fork's dynamo/main line because that is the local TensorRT-LLM baseline carrying the Dynamo-oriented filelock hardening used for this extraction.

[galletas1712]

FYI — the _weights_presharded handling here only protects three of the ~90 load_weight_shard(..., module.tp_size, module.tp_rank, ...) call sites across linear.py, fused_moe/quantization.py, fused_moe/fused_moe_triton.py, and triton_linear.py. The quantized and MoE paths still re-shard unconditionally.

Kimi failover doesn't exercise the unprotected sites (SIGTERM-kill + cold-boot, no reload), but the design is brittle.

#7 proposes moving the gate into load_weight_shard itself via an optional module= keyword. It's stacked on the integrated tip rather than in-place on this PR so it doesn't orphan the downstream PRs (#4, #5) and orphan commits. If/when we rebase the whole stack, #7 can be squashed into this PR.