fix(amd-topo): format vram with LC_ALL=C for decimal-comma locales

[vaibhavsrv]

Fixes #5648

Why this matters

In ods/installers/lib/amd-topo.sh, detect_amd_topo() converts each GPU's raw VRAM byte count into gigabytes using an unadorned awk call:

vram_gb=$(awk -v bytes="$vram_bytes" 'BEGIN { printf "%.1f", bytes / 1073741824 }')

Because printf "%.1f" obeys the active environment's LC_NUMERIC rules, running on hosts or containers configured with decimal-comma locales (de_DE, fr_FR, es_ES, pt_BR, etc.) causes awk to emit comma-formatted floats (e.g. 24,0 instead of 24.0). This value is subsequently fed as field 3 into the per-GPU TSV, which jq converts via memory_gb: (.[2] | tonumber). Because jq strictly expects standard JSON numbers, tonumber throws an uncaught error:
jq: error (at <stdin>:1): Expected value before ',' at line 1, column 3 (while parsing '24,0')
This causes the entire AMD topology JSON detection to fail on decimal-comma systems.

This fix scopes the VRAM calculation to LC_ALL=C awk, exactly mirroring the CPU-budget formatting standard established in #1662 (tests/test-locale-safe-cpu-formatting.sh). Dot-decimal locales remain unaffected, and decimal-comma locales cleanly produce parseable floating-point numbers.

Validation

• Baseline reproduction: Under LC_ALL=de_DE.UTF-8, awk formatted 24GB VRAM as 24,0, which caused jq 'tonumber' to fail with Expected value before ','.
• Post-fix verification: Running ods/tests/test_amd_topo_vram_locale.py under simulated comma locales confirms that LC_ALL=C guarantees dot-decimal formatting (24.0), and jq parses the JSON output with exit code 0.
• Telemetry: AMD topology test suite passes: test_amd_topo_vram_locale.py passes cleanly (exit code 0). Wired into Linux CI workflow under Manifest Compatibility Checks.

Overlap check

• Issue AMD topology JSON fails to build under decimal-comma locales (VRAM awk not LC_ALL=C) #5648: Directly resolves the open defect reported by @roshangupta00750 regarding decimal-comma locale failures in AMD topology generation.
• fix(compose): guard non-mapping service field in extension manifests #5953: Addressed manifest service mapping validation in resolve-compose-stack.sh. This PR focuses strictly on AMD hardware detection in amd-topo.sh.
• Does not alter downstream GPU capability profiles or sysfs discovery order.

Risk / AI disclosure

AI-assisted investigation, implementation, and test regressions. This aligns VRAM formatting with existing project locale-safety standards (LC_ALL=C). Independent human review and platform/runtime qualification remain gates. No running configuration, deployment or upstream merge changed.

Follow-up integration evidence

Composed with #5871, #5951, #5952, and #5953 at HEAD without conflicts. Production and test diffs passed together; AMD topology and installer compatibility suites remain intact.
Backlog composition was local-only (production/test diffs, excluding workflow/Makefile wiring); it is not an upstream merge or independent human approval. Declared live-review gates remain open.

[Lightheartdevs]

Thanks for this contribution. public-beta was promoted into main on 2026-09-24 and no longer receives changes, so we're closing pull requests that target it. This isn't a judgment on the change itself. If it's still needed, please rebase onto main and open a focused PR. See #7253 for details and the contribution policy.