[None][chore] add startup efficiency review group

[chienchunhung]

Summary

Propose @NVIDIA/trt-llm-startup-devs as a cross-cutting review group for TensorRT-LLM startup efficiency and add it as a co-owner of the startup-critical implementation, test, and documentation paths that exist today.

The intended boundary is model/engine time-to-ready and warm resume: checkpoint discovery and loader contracts, MX/GMS integration, reusable weight compatibility, GPU-memory attachment and staging, stable virtual-address lifecycle, engine initialization, and future snapshot/warm-resume integration.

Why this name

trt-llm-startup-devs is broad enough to cover cold start, warm resume, model loading, and new snapshot-based paths without implying ownership of all runtime launch/orchestration code.

• trt-llm-launch-devs: less precise; “launch” can mean CLI/process launch, kernels, or Dynamo orchestration.
• trt-llm-model-startup-devs: precise, but longer and unnecessarily excludes engine-level initialization.
• trt-llm-fast-start-devs: emphasizes performance but understates correctness and compatibility ownership.
• trt-llm-model-loading-devs: too narrow for GMS, stable-VA, staging, warmup, and snapshot resume.
• trt-llm-readiness-devs: captures time-to-ready, but is less immediately recognizable.

Proposed coverage

• Base checkpoint/config/weight loader contracts and HF loader implementations.
• MX checkpoint loading and AutoDeploy's weight-loading transform.
• GMS memory backend and focused GMS/MX loader integration tests.
• Reusable weight artifact/source identity and post-transform compatibility profiles.
• Virtual-memory/stable-VA and pinned-weight staging primitives used by reuse paths.
• Model loader, engine initialization/warmup, and direct startup documentation/tests.

The existing runtime, models, AutoDeploy, disaggregation, and documentation teams remain co-owners. Model-specific weight mappers, broad LLM configuration, unrelated executor code, steady-state inference performance, external MX/GMS/Snapshot implementations, Dynamo orchestration, and the legacy TensorRT backend remain outside the automatic ownership boundary.

Future startup-specific modules should be added explicitly rather than assigning the new team to broad directories. In particular, snapshot/warm-resume paths should be added when their TRT-LLM integration files land.

Approval behavior

GitHub treats multiple owners on one CODEOWNERS rule as alternatives: approval from any one listed owner can satisfy code-owner review. This change therefore adds startup review routing while retaining current owners; it does not require separate approval from every team.

If mandatory approval from both the startup group and the existing domain owner is desired, that needs a follow-up policy check or review bot because CODEOWNERS alone cannot express AND semantics.