I'm first author of the linked paper and am working on Pallene for my PhD. Feel free to ask any questions here!
If you want to produce a standalone executable, at the end of the day this executable will contain a copy of the Lua VM.
If you want to produce a library that can be "require"-ed from Lua, then you will produce a ".so" shared object file with just the Pallene functions in it.
Roughly speaking, from the point of view of Lua, Pallene is a system language like C. It is good for performance and calling C system libraries, but isn't particularly suited for dynamic code loading and sandboxing via interpreter hooks.