Set TRITON_CACHE_DIR in the Jetson 6.2.0 image

What

Adds TRITON_CACHE_DIR=/tmp/triton-cache to the runtime ENV block of
docker/dockerfiles/Dockerfile.onnx.jetson.6.2.0, next to the existing
ORT_TENSORRT_ENGINE_CACHE_PATH=/tmp/ort_cache. One line, plus a unit test in
tests/inference/unit_tests/deployment/test_jetson_triton_cache_dir.py (same style as
test_model_trust_defaults.py): every Jetson image that ships Triton and does not pin RF-DETR to the base
preprocessor must set TRITON_CACHE_DIR=/tmp/triton-cache. It fails on main (naming 6.2.0) and passes on this
branch.

Why

RF-DETR preprocessing JIT-compiles Triton kernels
(inference_models/inference_models/models/rfdetr/triton_preprocess.py). With no TRITON_CACHE_DIR, Triton's
cache manager creates ~/.triton/cache, i.e. /root/.triton/cache. The
Jetson install docs
run the container with --read-only and only /tmp mounted writable, so every RF-DETR request
fails with HTTP 500:

OSError: [Errno 30] Read-only file system: '/root/.triton/cache'
  .../rfdetr/triton_preprocess.py -> triton/runtime/driver.py -> triton/runtime/cache.py:69 os.makedirs

YOLOv8 models on the same server are unaffected (no Triton path). The JetPack 7.2.0 image already sets
TRITON_CACHE_DIR=/tmp/triton-cache (Dockerfile.onnx.jetson.7.2.0:593, asserted by
docker/scripts/verify_jetson_server_runtime.sh:9); this brings 6.2.0 in line with the same value.

How it was tested

• Device: Jetson Orin Nano 8 GB (Super), JetPack 6.2.1 (L4T R36.4.7).

• Image: published roboflow/roboflow-inference-server-jetson-6.2.0:latest (server reports Inference 1.7.2),
  started with the documented hardened command (--read-only, /tmp volume, --cap-drop=ALL,
  no-new-privileges).

• Before: rfdetr-nano, rfdetr-base, rfdetr-medium -> HTTP 500 with the trace above; yolov8n-640 -> OK.

• After: same image and command plus -e TRITON_CACHE_DIR=/tmp/triton-cache at runtime (equivalent to the
  ENV line in this PR), no other Triton variable set, starting from an empty cache -> all three RF-DETR sizes return
  predictions (person 0.90-0.96 on two 1280x720 test frames). /tmp/triton-cache did not exist before the first
  request and held 24 compiled files afterwards, so Triton compiled into exactly the path this PR sets.

• Commands (the -e MAX_ACTIVE_MODELS, ACTIVE_LEARNING_ENABLED and TELEMETRY_OPT_OUT flags were also set
  and are unrelated to this change):

  sudo docker run -d --name inference-server --runtime nvidia --read-only -p 127.0.0.1:9001:9001 \
    --volume /opt/nvme/inference-cache:/tmp:rw --env-file ~/.roboflow.env \
    -e TRITON_CACHE_DIR=/tmp/triton-cache \
    -e MAX_ACTIVE_MODELS=2 -e ACTIVE_LEARNING_ENABLED=False -e TELEMETRY_OPT_OUT=True \
    --security-opt=no-new-privileges --cap-drop=ALL --cap-add=NET_BIND_SERVICE \
    roboflow/roboflow-inference-server-jetson-6.2.0:latest

  # run once per model_id in rfdetr-nano, rfdetr-base, rfdetr-medium, on two 1280x720 JPEG frames
  import base64, json, os, urllib.request
  body = json.dumps({"model_id": "rfdetr-base", "api_key": os.environ["ROBOFLOW_API_KEY"], "confidence": 0.4,
                     "image": {"type": "base64", "value": base64.b64encode(open("frame.jpg", "rb").read()).decode()}}).encode()
  req = urllib.request.Request("http://127.0.0.1:9001/infer/object_detection", data=body,
                               headers={"Content-Type": "application/json"})
  print(json.load(urllib.request.urlopen(req))["predictions"])

• Unit test: pytest tests/inference/unit_tests/deployment/test_jetson_triton_cache_dir.py -> 1 passed
  (and 1 failed against main's Dockerfile). black --check and isort --check-only pass on the new file.

• Not done: rebuilding the 6.2.0 image from this Dockerfile (Triton is compiled from source; not feasible on the
  test device). The verification uses the published image with the variable set at runtime.

Related (not in this PR)

By code inspection only (not tested on x86 GPU hardware): Dockerfile.onnx.gpu and Dockerfile.onnx.cu13.gpu ship the
Triton JIT toolchain for RF-DETR preprocessing but do not set TRITON_CACHE_DIR, and the Linux GPU install docs also
use --read-only with a /tmp volume, so they may hit the same error. Happy to follow up after testing on a GPU host.

On an 8 GB Orin Nano, loading several models with the default MAX_ACTIVE_MODELS produced
CUBLAS_STATUS_ALLOC_FAILED (nvmap ENOMEM); -e MAX_ACTIVE_MODELS=2 avoided it. Happy to open a separate docs PR
for an 8 GB note if that is useful.

Investigation and draft prepared with Claude Code; tested on-device and reviewed by me.