record(SERVE-C-ABI): the ELF export guarantee is the version script alone, and the Apple leg links without it (#1535)

[localai-bot]

cmake/vllm_export.map makes every non-vllm_* symbol in the force-linked
vllm archive local, which is what keeps examples/video_studio/main.cpp safe
by construction: it links vllm::shared, vllm_shared links vllm PRIVATE, so
the example compiles the vendored httplib header in the no-TLS layout while the
library holds the TLS layout. CPPHTTPLIB_OPENSSL_SUPPORT is a whole-header
switch over httplib::Result and httplib::ClientConnection, so the two
definitions are ODR-incompatible and the script is what keeps them from meeting.

This closes nothing. It records what is true, because the measurement needs a
macOS host and this row has not taken one. SERVE-C-ABI had no ## Owed section
at all, so the only place the gap was written down was the issue index.

Three things the issue does not say, each read off this tree.

The version script is the ONLY mechanism. vllm_shared carries
CXX_VISIBILITY_PRESET hidden, which looks like a second line of defence and is
not: those properties apply to the target's own sources, and its only source is
the generated empty stub. A repo-wide grep for VISIBILITY_PRESET returns
exactly those two lines, so nothing compiles the archive hidden.

The ELF leg is now MEASURED rather than argued. One Release CPU build, one build
directory, libvllm.so.0.0.3 linked twice from the same objects with only the
--version-script argument removed: 48 dynamic defined symbols become 9376, of
which 9329 are non-vllm_* and 734 are httplib, split 505 W / 209 V / 20
u. That is the export set the Apple leg has.

"We have no macOS host" is the wrong summary. release.yml runs metal_arm64
and mlx_arm64 on macos-15. What it does not do is build either artifact this
question is about: build-macos-release.sh configures examples ON and then
builds --target server test_metal_backend, and server links vllm::vllm.
So the dylib is never linked there and video-studio is never compiled there.
The gap is a lane building the wrong two targets, not an absent machine.

One narrowing for whoever measures it: httplib::Result has no out-of-line
definition in either link, so grepping the export table for it finds nothing and
that is not reassurance. The exported weak family is httplib::ClientImpl and
its neighbours, whose signatures embed the layout-dependent types.

Refs #1535, which stays OPEN: this records the gap, it does not measure it.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]