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.

[UNORTHOD0xd]

Thanks @jeffcharles for the pointer! Updated the test to read the result discriminant from linear memory instead of expecting a trap. Should be green now.

[jeffcharles]

I'm seeing a formatting failure in CI. Again, would recommend running make ci just to double-check everything passes. We have some contributing docs in the docs directory you can review if you're finding that you're seeing errors around tools not being installed when running that.

Again though, thank you for submitting this PR! The better error message should help steer other plugin developers toward running init-plugin.

[UNORTHOD0xd]

The failure was just cargo fmt wanting the .get_memory() chain split across lines. CI should be green now. No problem, just happy to contribute. Cheers!

[jeffcharles]

Thank you again, this is a much nicer user experience and also helpful for providing direct feedback to LLMs