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, 6 insertions, 0 deletions

diff --git a/crates/shirabe/src/plugin/capability/capability.rs b/crates/shirabe/src/plugin/capability/capability.rs
index aa70ffa0..bb634b9f 100644
--- a/crates/shirabe/src/plugin/capability/capability.rs
+++ b/crates/shirabe/src/plugin/capability/capability.rs
@@ -11,4 +11,10 @@ pub trait Capability {
     fn as_command_provider(&self) -> Option<&dyn CommandProvider> {
         None
     }
+
+    /// For testing only: recovers the PHP-backed proxy so tests can read capability properties
+    /// the way PHPUnit asserts `$capability->args`.
+    fn __as_php_capability_proxy(&self) -> Option<&crate::plugin::PhpCapabilityProxy> {
+        None
+    }
 }