feat(llm): propagate deployment request concurrency to Pylon

Is this related to a problem? Please describe.

NVCF deployment GPU specifications define maxRequestConcurrency, but that deployment field is not carried as a typed value through the ICMS launch specification to the workload translator. Pylon therefore starts without a static --max-engine-concurrency value.

When the inference engine does not publish max_engine_concurrency, Pylon advertises the limit as unknown. WaitAndWiden then cannot compare running load against the worker's configured capacity. A worker with more available concurrency can appear more loaded than it is.

Describe the solution you'd like

Propagate the selected deployment GPU specification's maxRequestConcurrency value through the launch path:

NVCF deployment -> ICMS launch specification -> worker queue message -> Pylon

Configure Pylon with:

--max-engine-concurrency=<deployment maxRequestConcurrency>

The typed deployment field must be authoritative. The existing MAX_REQUEST_CONCURRENCY worker environment value may remain as a mixed-version rollout fallback for older queue messages.

Treat the Pylon argument as a static fallback. A live max_engine_concurrency value reported by the inference engine must continue to take precedence.

Definition of done:

• Container-based and Helm-based LLM workers receive the deployment GPU specification's maxRequestConcurrency value.
• The value is preserved as a typed launch specification field through ICMS and the worker queue message.
• Pylon receives the value as --max-engine-concurrency.
• The typed deployment value takes precedence over the legacy environment value.
• Translation tests verify the generated Pylon arguments.
• Existing Pylon behavior remains unchanged when live engine stats report a concurrency limit.

Describe alternatives you've considered

• Read only from MAX_REQUEST_CONCURRENCY. This obscures the value's deployment origin and makes an opaque environment payload the launch contract.
• Wait for Dynamo to stream dynamic capacity statistics. This is the preferred long-term source, but it is not available yet.
• Configure a separate static Pylon value. This can diverge from the function deployment setting and creates two capacity controls.

Additional context

Pylon already supports --max-engine-concurrency N as a positive fallback when the engine does not report a limit.

Relevant code:

• src/control-plane-services/cloud-functions/nvcf-core/src/main/java/com/nvidia/nvcf/icms/client/IcmsClient.java
• src/control-plane-services/instance-cluster-management/icms-core/src/main/java/com/nvidia/icms/service/byoc/ByocMessageGenerator.java
• src/libraries/go/lib/pkg/icms-translate/translate/function/llm.go
• src/libraries/rust/stargate/crates/pylon/src/main.rs

By submitting this issue, you agree to follow our code of conduct and our contributing guidelines.

Start with IcmsClient.java, ByocMessageGenerator.java, llm.go, and Pylon's src/main.rs to trace the launch specification through the queue message into generated arguments. Run the existing translation tests and add coverage for container and Helm worker paths. Done means the typed deployment value reaches Pylon, overrides the legacy environment fallback, and live engine statistics still take precedence.