[Linux][Inference] NEMOCLAW_VLLM_PORT accepts noncanonical leading-zero port (08000), silently normalized to 8000 instead of rejected

## Description

NEMOCLAW_VLLM_PORT accepts a noncanonical leading-zero port string (`08000`) and silently normalizes it to canonical port `8000` during managed vLLM onboarding, instead of rejecting it before install.

Platform scope: Reproduced on Linux x86_64 only; other platforms not tested.
Regression: Unknown - earlier versions not tested.

## Environment

```text
Device: Linux x86_64 server, NVIDIA GeForce RTX 5090 D
OS: Ubuntu, Linux 6.17.0-23-generic
Architecture: x86_64
Node.js: v22.23.0
npm: 10.9.8
Docker: 29.7.2
OpenShell CLI: 0.0.116
NemoClaw: v0.0.124
OpenClaw: 2026.7.1
```

## Steps to Reproduce

1. Confirm a compatible managed vLLM profile:
```bash
nemoclaw profiles list
```
2. Run:
```bash
NEMOCLAW_VLLM_PORT=08000 nemoclaw onboard --profile {compatible-vllm-profile-id} --name vllm-invalid-port --yes --non-interactive --yes-i-accept-third-party-software
```
3. For contrast, run the same command with `NEMOCLAW_VLLM_PORT=1023` (below range) and separately with `NEMOCLAW_VLLM_PORT=65536` (above range).
4. Inspect the sandbox inventory (`nemoclaw list`) and `docker ps` / `nvidia-smi` after each attempt.

## Expected Result

Step 2: exit nonzero; output rejects the noncanonical port representation `08000` before install begins, and no sandbox, model download, or managed container is created.

Step 3 (control): both out-of-range values rejected the same way.

## Actual Result

Step 2: exit 0. Onboarding completes fully, sandbox `vllm-invalid-port` reaches Ready, and the managed vLLM Docker container listens on canonical port 8000 (confirmed via `docker ps`, port mapping `nemoclaw-vllm: 0.0.0.0:8000 mapped to 8000/tcp, [::]:8000 mapped to 8000/tcp`). The onboarding also re-points the one shared inference route on the OpenShell gateway to `vllm-local` for every other registered sandbox on that gateway.

Step 3 (control): both out-of-range values correctly reject with exit 1 and the message: `Error: Invalid port: NEMOCLAW_VLLM_PORT="{value}" - must be an integer between 1024 and 65535`. This proves the port RANGE validator itself works correctly — the defect is specifically a string-format validation gap (a leading zero bypasses validation, most likely because the value is parsed with something equivalent to `parseInt()` before the range check, without ever validating the string representation itself), not a general range-check failure.

Reproduced cleanly 4 times total across one test session, including a final clean re-verify with a fresh GPU state and no leftover containers from prior attempts.

## Logs

```text
$ NEMOCLAW_VLLM_PORT=08000 nemoclaw onboard --profile vllm.linux-amd64-nvidia.single.nemotron-3-nano-4b-fp8 --name vllm-invalid-port --yes --non-interactive --yes-i-accept-third-party-software
...
Start chatting
Browser:
http://127.0.0.1:18796/
Terminal:
nemoclaw launch vllm-invalid-port
(exit code 0)

$ docker ps --filter "name=vllm" --format "{{.Names}}: {{.Ports}}"
nemoclaw-vllm: 0.0.0.0:8000 mapped to 8000/tcp, [::]:8000 mapped to 8000/tcp

$ nemoclaw list
vllm-invalid-port *
agent: openclaw model: nvidia/NVIDIA-Nemotron-3-Nano-4B-FP8 provider: vllm-local sandbox GPU

Control - out-of-range values, both correctly rejected:
$ NEMOCLAW_VLLM_PORT=1023 nemoclaw onboard --profile vllm.linux-amd64-nvidia.single.nemotron-3-nano-4b-fp8 --name vllm-invalid-port --yes --non-interactive --yes-i-accept-third-party-software
Error: Invalid port: NEMOCLAW_VLLM_PORT="1023" - must be an integer between 1024 and 65535
(exit code 1)

$ NEMOCLAW_VLLM_PORT=65536 nemoclaw onboard --profile vllm.linux-amd64-nvidia.single.nemotron-3-nano-4b-fp8 --name vllm-invalid-port --yes --non-interactive --yes-i-accept-third-party-software
Error: Invalid port: NEMOCLAW_VLLM_PORT="65536" - must be an integer between 1024 and 65535
(exit code 1)
```