Extism loader for the uni-db plugin framework.

uni-plugin-extism is the user-facing WASM loader. It sits parallel to uni-plugin-wasm (the Component Model loader). It follows the "Option C" hybrid pattern:

• Component Model (uni-plugin-wasm) — typed WIT contracts, capability gating by linker absence, used for the Lua-host, trusted built-ins, and plugins where soundness is load-bearing.
• Extism (this crate) — bytes-in / bytes-out, runtime-checked capabilities, used for user-authored UDFs that benefit from Extism's mature 13-language host SDK story.

Trust is a property of the granted CapabilitySet, not of which ABI a plugin happens to use. A user can author a "trusted" plugin in Extism by granting it broad capabilities; a built-in can author against Extism if the structural advantages of CM aren't load-bearing for its use case. The framework intentionally decouples ABI choice from trust tier.

Crate status

Loader is wired through the extism-sdk. ExtismLoader::load runs a two-pass instantiation (manifest probe, then plugin build) and surfaces failures as [ExtismError::Instantiate]. The host-fn registration surface ([HostFnRegistry]) and capability gating model are in place; the NotYetImplemented placeholder has been retired.

Why two WASM loaders

The proposal's loader matrix (§5.1) keeps the four authoring categories (compile-time Rust, WASM, PyO3, Lua) but splits the WASM row into two ABIs. Both ABIs converge on the same PluginRegistrar — the executor cannot tell whether a registered ScalarPluginFn was authored against WIT or Extism. The two loaders share the wasmtime runtime (Extism is itself wasmtime-backed), so the runtime cost is one wasmtime process, not two.