`cmt_rollup_finish` leaves machine in undefined state after rejected requests

[edubart]

Context

When using the libcmt and cartesi-machine low-level APIs, calling cmt_rollup_finish after a rejected request leaves the machine in an undefined state. Attempting to send a subsequent request results in corrupted behavior where the next request is processed with residual data from the previous rejected request.

Expected behavior: Either prevent subsequent requests after rejection, or properly handle the next request.

Current behavior: The API allows subsequent requests but processes them in a corrupted state with undefined behavior.

This creates a fragile testing experience for developers building test frameworks using local machines (no fork support) and libcmt APIs.

Possible solutions

1. Modify cmt_rollup_finish to always populate finish->next_request_type and finish->next_request_payload_length for all request outcomes, including rejections. This enables test frameworks to safely chain requests on local machines.
2. Have cmt_rollup_finish enter an infinite rejection loop or halt the machine after a rejected request, making the error state explicit.
3. Leave the API unchanged but explicitly document the undefined behavior after rejections.