Batch session protocol

Batch reads use a consume-on-confirm contract so that an item is only removed from the backend after the consumer has confirmed it was processed (for example, successfully sent to the cloud). A typical session looks like this:

1. 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. Consumer calls storage_batch_read() to read the head item. This call does not remove the item from the backend.
4. After the item has been processed, 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 -EAGAIN, or until the consumer decides to stop.
6. 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.