VPI/DPI 'apply' helpers that look up a symbol by name: allowlist entry points at registration so a request cannot call libc

Pattern seen in a simulator control library: a command took a function name from the request, looked it up with dlsym(RTLD_DEFAULT, name) inside the simulator process and called it. Any loaded symbol was reachable, including libc's system() or getpid(). It runs as the same user, so no privilege escalation, but a request could choose what code runs.

Fix that held up in review: - Build a fixed allowlist when the library registers (vlog_startup_routines / registration time): the library's own entry points plus names declared in a run manifest the launcher controls. - Pass the manifest list to the simulator through an env var the library reads once, then unsets. - Check every name the request supplies (main symbol, version symbol, last-error symbol), not just the main one, before any lookup. Return a clear error naming the refused symbol. - Validate manifest entries as C identifiers with a count cap. - Red test with a harmless probe: ask for getpid and show the return value is the pid on the unfixed code. Never use a shell command as the probe.

Scope note: whoever writes the manifest can still list any name, but they could already set LD_PRELOAD, so that isn't a new opening. What closes is the request choosing what to call.