[TASK] Report the API error code and HTTP status on failed requests

[CybotTM]

A failed request reports the API's message and nothing else. That message is not always specific enough to act on: TER answers every server-side exception it masks with the same generic text, so the console line looks identical for unrelated defects.

{"status": 500, "code": 1603956982, "message": "An error occured on handling the request."}

The code identifies which branch produced the response, and it is currently discarded. This PR reports it next to the HTTP status.

Before / after

Same command, same response, against a stub returning the body above:

Before

Updating meta information of extension my_ext
=============================================

 [WARNING] Could not update meta information of extension my_ext.
           Reason: An error occured on handling the request.

After

Updating meta information of extension my_ext
=============================================

 [WARNING] Could not update meta information of extension my_ext.
           Reason: An error occured on handling the request. (HTTP 500, code
           1603956982)

Across the response shapes the API actually produces:

Response	Before	After
{"status":500,"code":1603956982,"message":"An error occured…"}	An error occured…	An error occured… (HTTP 500, code 1603956982)
{"message":"Extension key not found."}	Extension key not found.	Extension key not found. (HTTP 404)
(empty body)	Unknown (Status 502)	Unknown (HTTP 502)

A response without a usable code only gains the status; the third row is a wording change, so that the suffix is the same in all three cases.

Why this matters in practice

In #98 the behaviour behind that generic line had to be reconstructed entirely from outside the tool — repeated calls against the production TER, comparing what the listing had stored afterwards. The cause turned out to be a masked exception in TER's RouteHandler, which is precisely what code 1603956982 denotes. Printed on the first call, it would have pointed straight there.

Details

The reason is built by RequestService::createFailureReason(), which is unit tested. Codes that carry no information — absent, empty, 0 or non-scalar — are omitted. error_description keeps precedence over message.

Verified with composer tests:unit (63 tests, 179 assertions) and composer cs. The transcripts above are captured output, not illustrations.