fix(php-rpc): panic on RPC failure instead of silently swallowing it

Worker spawn failure, socket I/O errors, and unparseable responses used to
fall back to plausible-looking defaults (empty string, false, None), making
real failures indistinguishable from legitimate PHP-side results. Panicking
is not the final design, but replaces silent data corruption with a loud
failure until proper error propagation is implemented.

1 files changed, 5 insertions, 3 deletions

diff --git a/docs/dev/php-rpc.md b/docs/dev/php-rpc.md
index ad5d3f1..1ec8171 100644
--- a/docs/dev/php-rpc.md
+++ b/docs/dev/php-rpc.md
@@ -16,9 +16,11 @@ The crate supports exactly one interaction pattern, and nothing else:
 - Rust to PHP only. PHP never calls back into Rust.
 - Exactly one argument, and it must be a string.
 - Scalar return values only (string / int / float / bool / null).
-- Every failure is ignored: a PHP exception, serialization/deserialization
-  failure, a missing PHP function, a crashed child, etc. None are handled.
-  If anything goes wrong, behavior is undefined.
+- Every failure `panic!`s: a PHP exception (not currently possible — the glue script never lets
+  one escape), a serialization/deserialization failure, a missing PHP function, a crashed child,
+  etc. None are handled as recoverable errors. This is not the final design — a future revision
+  will replace these panics with proper `Result` propagation — but panicking beats silently
+  returning a plausible-looking default.
 - Windows is unsupported and `panic!`s for now.
 
 ## Locating PHP