feat(host): implement Registerable for MultiUseSandbox

[danbugs]

Summary

Extends the Registerable trait impl to MultiUseSandbox so host functions can be registered on a sandbox after evolve(). Today the only impl is on UninitializedSandbox, which works fine for the standard Uninitialized → evolve() → MultiUse flow — but not for paths that yield a MultiUseSandbox directly. Examples: sandboxes loaded from a persisted snapshot (the snapshot-to-disk work lands one such path), and any future API with the same shape.

Without this, those callers have to reach into internal state or maintain a parallel registry, which isn't a stable story. With it, late registration becomes a one-liner that mirrors the existing UninitializedSandbox impl exactly.

Semantics

The guest's host-function dispatcher resolves by name at call time. Inserting into the registry after evolve() is safe as long as the first host-call invocation happens after registration completes. The typical usage pattern is the same as today for the pre-evolve path:

let mut sbox = MultiUseSandbox::from_snapshot(s)?;
sbox.register_host_function("__dispatch", |payload: Vec<u8>| { ... })?;
sbox.call::<(), _>("run", args)?;

Changes

• New impl Registerable for MultiUseSandbox next to the existing UninitializedSandbox impl in src/func/host_functions.rs. Body is a verbatim copy of the existing impl — same error handling, same lock acquisition, same FunctionEntry construction.
• Visibility of MultiUseSandbox.host_funcs nudged from pub(super) to pub(crate) so the impl in src/func/ can reach it. No external API change.

Tested

cargo check + cargo test -p hyperlight-host locally on Linux. No behaviour change for any existing caller.

[jprendes]

LGTM.

I guess this opens some questions, like what's the point of the UninitializedSandbox?
Sounds like it's only use is "existing before hyperlight_main".
Do we still need it?