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/docs/dev/php-rpc.md b/docs/dev/php-rpc.md
index 9e49dec0..314386d8 100644
--- a/docs/dev/php-rpc.md
+++ b/docs/dev/php-rpc.md
@@ -196,6 +196,12 @@ by `scripts/plugin-stub-generator/generate-stubs` and must not be edited by hand
   surface (`getIO()`/`getComposer()`/...) answers from the Rust handoff.
 - `Shirabe\RustCommandStub` — the reverse stub for built-in commands registered into that
   application.
+- `Shirabe\RustPluginStub` and `Shirabe\RustCapablePluginStub` — proxy stubs for a plugin
+  implemented on the Rust side, which has no class of its own here. A plugin is normally PHP
+  code running in the worker; these stand in where Rust hands such a plugin to PHP code, as
+  `PluginManager::getPluginCapability` does when it passes the plugin to a capability
+  constructor. The Capable flavour exists because `$plugin instanceof Capable` decides whether
+  Composer asks a plugin for capabilities.
 - `Shirabe\MaterializedValue` — the PHP half of the materialized-value codec: the closed list of
   classes `unserialize()` may revive, and the hook that hands such an instance to `serialize()`
   in place of a handle descriptor.