Batch session protocol

Batch reads use a consume-on-confirm contract, so that the module only removes an item from the backend after the consumer has confirmed that it processed the item, for example by sending it to the cloud successfully. A typical session runs as follows:

1. The consumer publishes STORAGE_BATCH_REQUEST with a non-zero session_id.
2. The Storage module responds with STORAGE_BATCH_AVAILABLE, with data_len set to the number of items available, and primes the pipe with the head item. If there is no data, it sends STORAGE_BATCH_EMPTY, and you must still close the session.
3. The consumer calls storage_batch_read() to read the head item. This call does not remove the item from the backend.
4. After processing the item, the consumer publishes STORAGE_BATCH_CONSUME with the matching session_id and the data_type of the item. The Storage module removes the head item and primes the next one in the pipe.
5. Steps 3 and 4 repeat until storage_batch_read() returns -ENODATA, or until the consumer decides to stop.
6. The consumer publishes STORAGE_BATCH_CLOSE to end the session.

If the consumer reads without consuming, storage_batch_read() repeatedly returns the same head item. If a STORAGE_BATCH_CONSUME arrives with an unknown or mismatched data_type, the Storage module aborts the session with STORAGE_BATCH_ERROR to avoid silent stalls.