Responses/streams are row-count-capped, not byte-capped — amplification and client wedge

Severity: high.

### Summary

Batches are capped at 500 rows (`FETCH_NOTES_BATCH_SIZE`, `crates/node/src/database/sqlite/mod.rs:20`) with each note up to 512 KB, and no `max_encoding_message_size`/`max_decoding_message_size` is set anywhere. So:

- one ~20-byte `FetchNotes` request can pull a ~256 MB unary response, fully buffered in memory (amplification / memory-exhaustion lever, made worse by 4096 allowed concurrent requests);
- once 500 large notes accumulate past a client's cursor, every fetch of that batch **exceeds the client's default 4 MB decode limit** — the client can't decode, can't advance its cursor, and is permanently stuck. Same math applies to `StreamNotesUpdate` batches.

The decode side is also uncapped: the 512 KB `max_note_size` check runs only *after* tonic has decoded up to its 4 MiB default, so writes allocate ~8x the intended cap.

### Recommendation

- Cap batches by cumulative payload bytes (stop accumulating past ~1-3 MB, return the cursor) for both fetch and stream.
- Set explicit `max_encoding_message_size` and `max_decoding_message_size` (just above `max_note_size`) on the service.

Related: #46 (windowed pagination), #4 (pagination), #101 (cursor).

---
Part of #114.

The issue points to `crates/node/src/database/sqlite/mod.rs:20` where `FETCH_NOTES_BATCH_SIZE` is defined. Examine the fetch and stream logic in the database and gRPC service layers to understand how batches are assembled. Look for where to add a cumulative byte size check and where to set `max_encoding_message_size` and `max_decoding_message_size` in the tonic service configuration. Testing involves verifying that large note batches are split correctly and that decode limits are enforced.

Scritto dal modello di indicizzazione a partire dal testo della issue.