[HackTuah]

Slice 133's AC12, landed on its own ahead of the rest of the slice (owner decision D5). To merge after #115.

What changes

The desktop release's applications are chosen per Burrito target from the BURRITO_TARGET that package.yml sets on each job. linux_x86_64 carries no exla. macOS and Windows keep what the host declares, the headless release is unchanged, and a local mix release desktop with no target behaves as before.

Why it costs nothing

The exla NIF never loaded in the Linux bundle: Burrito's musl ERTS cannot load XLA's glibc library (__libc_single_threaded, package run 35600216451). The bundle already booted with the local embedder off and scored through the Elixir path in VectorStores.Brute. The 68.7 MB it added (slice 032's measurement) did nothing.

Nothing depends on exla at runtime: no application in the tree lists it, and bumblebee declares it only: [:dev, :test].

Evidence

• test/release_composition_test.exs, 3 tests. Red first: with the Linux clause planted back to exla_release_applications(), 2 of 3 passed and "the Linux bundle leaves exla out" failed. With the change, 3 of 3 passed.
• BURRITO_TARGET=linux_x86_64 mix run --no-start -e 'IO.inspect(Mix.Project.config()[:releases][:desktop][:applications])' printed [].
• The package run on this branch (mix.exs is in its path filter) provides the bundle's half: the Linux artifact's size against the last run, and its TRINITY_SMOKE_EXLA line.

Local gate: not green, stated rather than hidden

Two local mix gate runs, with the machine at load average 25 to 27 from unrelated work:

• run 1: 961/963. SandboxTest "a Lua error is a value" got {:timeout, 1000}; Subagents.SupervisionTest AC4 got :killed for {:child_died, _}.
• run 2: 962/963. SandboxTest "more work reports more reductions".

All three are wall-clock or race-sensitive tests in files this change does not touch. The sandbox and supervision files passed 3 of 3 when run alone on this branch. Coverage was 80.31% against 80.31%, OK. The CI gate on clean runners is the result to read.

[HackTuah]

Package evidence, Linux x86_64 job, this branch (run 37722993386, job 113135556636) against main's last package run (run 37683782307, job 113007716600):

	main 5c1a9ba's predecessor run	this branch
desktop_linux_x86_64	94,442,360 bytes	28,152,040 bytes
TRINITY_SMOKE_VEC	ok:Trinity.Memory.VectorStores.Brute	ok:Trinity.Memory.VectorStores.Brute
TRINITY_SMOKE_SEMANTIC	off:{:exla, "the EXLA NIF did not load (EXLA.NIF.start_log_sink undefined)"}	off:{:exla, :not_compiled}

The bundle is 66,290,320 bytes smaller (70.2%). That is measured on this artifact, and it is not slice 032's 68.7 MB figure, which was taken on a different build. Behaviour is unchanged: semantic memory was off before and is off now, the vector store answers through the same Elixir path, and only the reason for being off changes, from a NIF that failed to load to one that is not there. Turning semantic memory on in this bundle is the static embedder's job, the second half of AC12, which stays with slice 133.

All checks are green on 2308c73, including the three package targets.