feat(plugin): activate plugins through the PHP RPC worker

Implement the remainder of PluginManager::registerPackage: the plugin
autoload map is built by the ported createLoader/parseAutoloads and
served to the worker over the existing reverse-RPC autoloader, files
entries go through a composerRequire-equivalent glue call, and
already-defined classes take the upstream _composer_tmp rename/eval
path. Instantiation uses the new NewObject/CallPhpMethod lanes backed
by a P table in the worker; PhpPluginProxy adapts the resulting handle
to PluginInterface, with $composer/$io exposed to plugin callbacks via
an R table (unsupported methods stay explicit errors). Hand-written
proxy stubs cover Composer, PartialComposer and the IO hierarchy, and
the stub autoloader is re-prepended after loading the Composer PHP
runtime so its vendor autoloader cannot shadow proxied FQCNs.

FilesystemRepository::write now mirrors InstalledVersions::reload into
a running worker (class_exists-guarded, so an unloaded class keeps its
upstream lazy-load behavior), removing the previously undefined
observation window.

The installer pipeline passes the installed repository as a shared
handle instead of a long-lived `&mut dyn`: plugin registration runs
inside InstallationManager::execute and re-enters the same local
repository through the RepositoryManager, which would panic on the
RefCell re-borrow under the old shape.

PluginInterface lifecycle methods now take an owned ComposerHandle
(plugins retain $composer past the call) and return anyhow::Result
(PHP plugin code may throw); the plugin list uses shared ownership so
the identity comparison of removePlugin survives the dual storage in
registeredPlugins, matching PHP reference semantics.

Ports the activate/upgrade/uninstall tests of PluginInstallerTest,
serialized across the shared worker process whose persistent class
table is exactly what exercises the rename path.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

1 files changed, 18 insertions, 6 deletions

diff --git a/crates/shirabe/src/plugin/plugin_interface.rs b/crates/shirabe/src/plugin/plugin_interface.rs
index 5a92a87a..54fa6009 100644
--- a/crates/shirabe/src/plugin/plugin_interface.rs
+++ b/crates/shirabe/src/plugin/plugin_interface.rs
@@ -7,23 +7,29 @@ use crate::plugin::Capable;
 pub const PLUGIN_API_VERSION: &str = "2.9.0";
 
 pub trait PluginInterface: std::fmt::Debug {
+    // The PHP methods return void but may throw; the owned `ComposerHandle` follows the shared
+    // handle policy — plugins typically store `$composer` beyond the call.
     fn activate(
         &mut self,
-        composer: &ComposerHandle,
+        composer: ComposerHandle,
         io: std::rc::Rc<std::cell::RefCell<dyn IOInterface>>,
-    );
+    ) -> anyhow::Result<()>;
 
     fn deactivate(
         &mut self,
-        composer: &ComposerHandle,
+        composer: ComposerHandle,
         io: std::rc::Rc<std::cell::RefCell<dyn IOInterface>>,
-    );
+    ) -> anyhow::Result<()>;
 
     fn uninstall(
         &mut self,
-        composer: &ComposerHandle,
+        composer: ComposerHandle,
         io: std::rc::Rc<std::cell::RefCell<dyn IOInterface>>,
-    );
+    ) -> anyhow::Result<()>;
+
+    /// PHP: `get_class($plugin)`. Rust has no runtime class name, so each implementor carries
+    /// the name PHP would report.
+    fn get_class_name(&self) -> String;
 
     // TODO(plugin): PHP-side `instanceof` checks for EventSubscriberInterface / Capable.
     // EventSubscriberInterface is not dyn-compatible (its only method is associated, not
@@ -35,4 +41,10 @@ pub trait PluginInterface: std::fmt::Debug {
     fn as_capable(&self) -> Option<&dyn Capable> {
         None
     }
+
+    /// For testing only: recovers the PHP-backed proxy so tests can read plugin properties the
+    /// way PHPUnit asserts `$plugins[0]->version`.
+    fn as_php_plugin_proxy(&self) -> Option<&crate::plugin::PhpPluginProxy> {
+        None
+    }
 }