Replace panicking unwrap with descriptive errors in plugin-api

[UNORTHOD0xd]

Summary

compile_src() and invoke() in javy-plugin-api call .unwrap() on RUNTIME.get(), which panics with an opaque message when the runtime has not been initialized:

thread '<unnamed>' panicked at crates/plugin-api/src/lib.rs:174:42:
called `Option::unwrap()` on a `None` value

This makes debugging difficult for plugin authors and host integrators, as the panic message gives no indication of what went wrong or how to fix it.

Changes

Replace the bare .unwrap() calls with .ok_or_else() returning a descriptive anyhow error that names the uninitialized runtime and points to initialize_runtime as the required precondition:

Javy runtime not initialized. Ensure `initialize_runtime` is called before `compile_src`.

Both functions already return Result<T>, so this is a non-breaking change with no new dependencies.

Context

This issue was encountered while building a Chainlink CRE workflow plugin. The javy host (v5.0.4) called compile_src before initialize_runtime, producing the opaque panic. The resulting error message (called Option::unwrap() on a None value) with a path pointing into the Cargo registry gave no actionable information about the root cause.

[jeffcharles]

You can run make ci to ensure your code will pass the linter and tests.

[jeffcharles]

We document requiring running javy init-plugin ... here so I'd recommend updating the error messages to include that javy init-plugin should be invoked. init-plugin initializes the runtime and saves the runtime into a series of data segments in the Wasm module that it outputs that RUNTIME references. Hypothetically someone could use this as a Rust library but we recommend using the lower-level javy crate for that use-case.

[UNORTHOD0xd]

Good call — updated both error messages to reference javy init-plugin instead. Thanks for the pointer to the extending docs.

[jeffcharles]

Looks like one of the integration tests is failing due to no longer trapping when the plugin is uninitialized. The test should be updated to read from the linear memory at the offset given by the return value. The first 4 bytes is the result variant which should be a non-zero value to indicate an error state.