fix: throw RequestError on addOrder error responses instead of a fatal TypeError - #258

Fixes #256

What happened in production

Seen 2026-09-21 with alma-installments-prestashop 4.16.0 (bundling client 2.6.1), PrestaShop 8.2, PHP 8.1 — full reproduction in #256. In short: Payments::addOrder() built an Entities\Order straight from an error response; end($res->json) handed a string to the constructor, whose $orderDataArray['comment'] raised TypeError: Cannot access offset of type string on string. A TypeError is an Error, not an Exception: it escaped every AlmaException/RequestError catch block of the module, and the merchant could not refund the order (back-office fatal) until the module was disabled.

The fix, at both layers

1. Payments::addOrder() now checks $res->isError() and throws RequestError — the exact sibling pattern already used by create(), edit(), addOrderStatusByMerchantOrderReference() and cancel, and already declared in the method's own docblock (@throws RequestError).
2. Entities\Order::__construct() rejects a non-array payload with ParametersException. Even with the endpoint fixed, any future payload-shape surprise would otherwise resurface as an Error that callers cannot catch; this makes the whole class of failure impossible.

Both changes are PHP 5.6-compatible (the repo's oldest supported line).

Validation

• tests/Unit/Endpoints/PaymentsTest.php — testAddOrderRequestError: mirrors testFullRefundRequestError (the mockServerRequestError helper gains an optional $requestMethod parameter, default 'post', because addOrder PUTs by default).
• tests/Unit/Entities/OrderTest.php — testOrderRejectsNonArrayPayload.
• Unit suite green: 241 tests / 354 assertions, OK (PHP 8.4 container; the 3 remaining Errors in the full run are the integration tests requiring live sandbox credentials, unrelated).