Unify sandbox types: initialize directly from snapshot and introduce HostFunctionRegistry

With #1392 adding `Registerable` to `MultiUseSandbox`, the split between `UninitializedSandbox` and `MultiUseSandbox` is increasingly hard to justify. Two changes could simplify the API:

- **Move initialization into snapshot loading**: Today, loading from a snapshot still goes through `UninitializedSandbox::from_snapshot() → evolve() → MultiUseSandbox`. If the snapshot path handled init directly and produced a `Sandbox` (or `MultiUseSandbox`) in one step, the two-phase flow could collapse and the uninitialized state becomes an internal detail rather than a user-facing type.
- **Introduce a `HostFunctionRegistry`**: Instead of registering host functions directly on the sandbox (as #1392 does today via the `Registerable` trait), a standalone registry object could be built up front and validated against the signatures the snapshot expects before the sandbox is created. This gives early type-checking and cleaner separation of concerns, replacing the current `Registerable` trait approach. (Note: internally a `FunctionRegistry` already exists — this would promote and reshape it into a public-facing API.)