Ensure correct error propagation for sequential replies

[alek-prykhodko]

Problem

There were two related issues when a decoding error occurred for a route using SequentialResultProvider:

1. If the message failed to decode, the SequentialResultProvider was already initialized. Its deinit would then send a finished status, incorrectly masking the decoding error.
2. The server's global catch block would close the XPC transaction without first sending a properly formatted error message that the client-side provider could interpret.

This resulted in the client receiving a finished status instead of an appropriate error.

---

Solution

This PR addresses the issue with a two-part fix:

1. Delayed Initialization: The SequentialResultProvider is now created only after the incoming message has been successfully decoded. This ensures that a decoding failure is thrown and caught before the provider is ever instantiated, preventing its deinit from sending a misleading finished status.

2. Corrected Error Handling: The server's error handling logic for sequential replies has been updated. It now explicitly sends a new XPC message containing the error details first, and only then closes the underlying XPC transaction.

These changes guarantee that decoding errors are correctly propagated to the client as an error state, not as a successful completion.