Unify sandbox types: initialize directly from snapshot and introduce HostFunctionRegistry #1402

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 feat(host): implement Registerable for MultiUseSandbox #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.)