feat(plugin): let a Rust-implemented plugin cross into the worker

PluginManager::getPluginCapability hands the plugin itself to the
capability constructor. Only a PHP-implemented plugin had an entity the
child could receive, so a Rust-implemented one bailed out; it now crosses
as a handle to an R-table entity behind Shirabe\RustPluginStub, or its
Capable flavour, since `$plugin instanceof Capable` is what decides
whether Composer asks a plugin for capabilities at all.

This is what the two capability tests of PluginInstallerTest were waiting
on: the mocked Capable plugin is Rust-side, and one of them asserts the
identity of the plugin read back out of $capability->args.

1 files changed, 7 insertions, 0 deletions

diff --git a/crates/shirabe/src/event_dispatcher/event_dispatcher.rs b/crates/shirabe/src/event_dispatcher/event_dispatcher.rs
index 72db0543..ca6c2adc 100644
--- a/crates/shirabe/src/event_dispatcher/event_dispatcher.rs
+++ b/crates/shirabe/src/event_dispatcher/event_dispatcher.rs
@@ -1586,6 +1586,13 @@ try {{
         Ok(())
     }
 
+    /// For testing only: a test that never registers a plugin package still needs the Composer
+    /// PHP runtime in the worker before a class of its own can implement a Composer interface
+    /// there.
+    pub fn __ensure_composer_php_runtime() -> anyhow::Result<()> {
+        Self::ensure_composer_php_runtime()
+    }
+
     fn composer_php_runtime_autoload() -> Option<String> {
         if let Some(dir) = Platform::get_env("SHIRABE_COMPOSER_PHP_DIR") {
             let path = std::path::Path::new(&dir)