ci: release 1.30.0

[kibae]

Summary

• Sync onnxruntime-server with upstream ONNX Runtime 1.30.0.
• Bumps version strings via deploy/update-version.sh 1.29.1 -> 1.30.0.
• Aligns the CUDA docker base images with what onnxruntime actually built against, which lowers the minimum driver for both GPU images.

Upstream surface review (1.29.1 -> 1.30.0)

• No new element data types. ONNX_TENSOR_ELEMENT_DATA_TYPE_* is identical between the two releases, so value_info::type_name / get_tensor_data / input_value.cpp need no change.
• No new mapped-enum members. GraphOptimizationLevel is still {DISABLE_ALL, ENABLE_BASIC, ENABLE_EXTENDED, ENABLE_LAYOUT, ENABLE_ALL} and ExecutionMode still {SEQUENTIAL, PARALLEL}; parse_graph_opt_level / parse_execution_mode and the openapi enums already cover every value.
• No new Ort::SessionOptions setters. The method set of SessionOptionsImpl is unchanged, so apply_session_options has nothing to expose.
• No public header added or removed.
• Three new symbols, none of which require code:
  • ORT_EXTERNAL_MEMORY_HANDLE_TYPE_{HOST_ALLOCATION,MEMORY_OPAQUE_FD,MEMORY_WIN32} — part of the new memory-importing API, which the server does not mirror.
  • kOrtSessionOptionsConfigEnableSavedRuntimeOptimizations and kOrtSessionOptionsMlasNchwcPointwiseConvMaxInputChannelBatch — config_entries forwards arbitrary keys verbatim, and the openapi docs describe the passthrough rather than enumerating keys, so there is no doc drift either.
• No new or renamed CUDA provider option keys in the release notes; src/onnx/cuda/session_options.cpp forwards keys verbatim regardless.
• Bundled ONNX stays at 1.22.0 (cmake/deps.txt identical in rel-1.29.1 and rel-1.30.0), so the opset 23 pin in test/sample-onnx-generator/sample-datatypes.py is still current.
• Release assets unchanged; onnxruntime-linux-aarch64-1.30.0.tgz is a valid archive again, so the nupkg fallback in download-onnxruntime.sh stays dormant as intended.
• The "Announcements & Compatibility" items (FP4 QMoE on by default, compact fpA-intB kernels, CPU FP16 Gemm/MatMul falling back to FP32) are build-flag and kernel-level changes with no C API surface.

Version-pinned assumptions re-validated (still true at 1.30.0, left unchanged)

• value_info.cpp / unit_test_value_info.cpp: onnxruntime still stores uint2 unpacked, one value per byte. The EXPECT_NE tripwire in unit_test_context did not fire.
• value_info.cpp / ComplexNotConstructibleInOrt127: onnxruntime still cannot allocate complex tensors.

Docker base images

c-api-noopenmp-packaging-pipelines-cuda13.yml pins the cuda13 package to CUDA 13.0 with cuDNN 9.14.0.64, and Dockerfile.manylinux2_28_cuda builds the cuda12 package on nvidia/cuda:12.8.1-cudnn-devel-ubi8. Our base images had drifted ahead of both, raising NVIDIA_REQUIRE_CUDA without onnxruntime ever using the newer CUDA APIs.

image	before	after	driver floor
linux-cuda13	13.1.1-cudnn (cuDNN 9.17.1.4)	13.0.3-cudnn (cuDNN 9.14.0.64 — exact match)	cuda>=13.1 -> cuda>=13.0
linux-cuda12	12.9.1-cudnn (cuDNN 9.10.2.21)	12.8.1-cudnn (cuDNN 9.8.0.87)	cuda>=12.9 -> cuda>=12.8

Moving in the opposite direction was measured and rejected: a 13.3.1-based image builds fine but fails docker run with unsatisfied condition: cuda>=13.3, and bypassing that with NVIDIA_DISABLE_REQUIRE=1 only defers the failure to session create (CUDA failure 100: no CUDA-capable device is detected). CUDA 13.3 needs driver >= 610, so every user on 590-609 would have lost the image with no workaround.

Test plan

• cmake build (Debug) and ctest pass locally against the onnxruntime 1.30.0 GPU binary (9/9).
• linux-cuda13 on 13.0.3-cudnn builds and passes docker-image-test.sh (CUDA device_id: 0, inference OK).
• linux-cuda12 on 12.8.1-cudnn builds and passes docker-image-test.sh (CUDA device_id: 0, inference OK).
• Cross-platform CI passes (Linux / Windows / macOS).
• Docker images built and pushed: linux-cpu (amd64+arm64), linux-cuda12, linux-cuda13.
• Update Docker Hub repository description after merge: https://hub.docker.com/repository/docker/kibaes/onnxruntime-server/general