Declare the opt-in modules in natives.csv, so the smokes know what the loader leaves out

[bernardladenthin]

First, what run 38164077038 answered — and it is the first time any of it has been

build jobs	54 green, both ROCm among them
ROCm Windows / Linux	3:08 h / 2:57 h — they are the three-hour pipeline; every other job finished inside an hour
verify-native-deps.py	99 native libraries checked, 0 violations

So the SYCL run path is clean and the Linux jars no longer declare libgomp.so.1 with nothing
noticing. package got past the dependency check for the first time.

Then it found this, and it is my own loose end

##[error]classpath: the loader did not put the openvino module jar of Linux/x86_64 in place

A consequence of making openvino opt-in, which I should have foreseen when I added
OPT_IN_BACKENDS: smoke-natives-jars.sh asserts the loader line names every GPU module of the
platform, read from natives.csv — and the list had no way to say that one of them is deliberately
left out.

The loader even printed the reason, one line above the failure:

[jllama] GPU module 'openvino' is on the classpath but not used: it is opt-in, because …

Nothing read it.

The fix: declare it where every consumer already looks

An optin column in natives.csv. check-natives.py validates it — yes/no, only a module can
be opt-in, and the rows of one backend cannot disagree, since the loader decides per backend — and
holds LlamaLoader.OPT_IN_BACKENDS to it in both directions:

• a backend the list calls opt-in while the loader does not → a jar that takes over silently, which is
  the measured OpenVINO regression the opt-in exists for;
• the reverse → a jar that is inert with no row saying why.

The two smoke layers read the same column, with different conditions

	expectation
smoke-lib.sh + the PowerShell twin (model-backed rows)	every module of the set except the opt-in ones — the loader leaves them out, and OpenVINO's CPU plugin would otherwise take over a server round and run 172× slower
smoke-natives-jars.sh (load-only)	names every module through net.ladenthin.llama.backend, opt-in included — it loads the library and exits, so nothing is at risk

That second row is the part I care about: it makes this script the only place in CI that loads an
opt-in module at all, so the mechanism is exercised rather than merely respected.

Verification

122 buildcheck tests (four new: the column's rules, and both directions of the constant check).
Both module lists and the property construction were simulated against the real natives.csv
locally rather than left to CI:

smoke_set_modules      -> cuda13 rocm sycl vulkan           (openvino correctly absent)
smoke-natives-jars.sh  -> cuda13 rocm sycl vulkan openvino  (named via the property)
no modules (macOS)     -> java gets no -D argument at all

check-run-scripts.py 161 scripts clean, check-release-gate.py 0 violations, check-natives.py
0 disagreements.

Still unproven

Everything behind smoke-natives-jars.sh was skipped, as in every run before: the five smoke
sets, the four smoke-natives rows with the RPC smoke on aarch64, the macOS smoke, the agent smoke.
Said in TODO.md rather than implied.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E2h8gXyyE5UeimkL9vQv9G

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud