fix(cf): recover managed service instance update from empty 202 body

[nabramovitz]

Problem

Editing a managed service instance's parameters failed with:

Failed to update service instance: parsing job response: unexpected end of JSON input

CF V3 answers PATCH /v3/service_instances/{guid} on a managed instance with 202 + an empty body, putting the job link in the Location header. The capi client library unconditionally unmarshals the response body as a Job, so the empty body produced the JSON parse error — even though CF had accepted the update and the broker operation was already under way. Non-empty parameters force a broker round-trip (async 202), which is why the bug only showed when parameters were supplied.

Fix

The create and delete paths already recover from this capi-client behavior; this adds the same recovery to the update path. When the parse error occurs, the handler now:

1. GETs the service instance and reads last_operation
2. Short-polls while the broker update is still in flight
3. Returns 502 with the broker's failure description if the update failed, or a fast-path COMPLETE envelope on success

so the user sees the real outcome instead of a client-side parse artifact.

Testing

• Two new handler tests reproduce CF's empty-202 response; both failed with the exact reported error before the fix and pass after (broker-succeeded and broker-failed outcomes)
• Full gate (backend + frontend suites) green

Follow up

The capi library will be modified to read the associated object from the header instead of assuming it is being returned in the body like many of the capi api calls.

Closes #5431

[norman-abramovitz]

A temporary fix is put in place to handle the CAPI library failing to return the object identifier in the body, as with many other CAPI calls. Once the CAPI library is fixed this temporary fix will be removed.