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.

Le problème pointe vers `crates/node/src/database/sqlite/mod.rs:20` où `FETCH_NOTES_BATCH_SIZE` est défini. Examinez la logique de récupération et de flux dans les couches de base de données et de service gRPC pour comprendre comment les lots sont assemblés. Cherchez où ajouter une vérification de taille cumulée en octets et où définir `max_encoding_message_size` et `max_decoding_message_size` dans la configuration du service tonic. Les tests impliquent de vérifier que les grands lots de notes sont correctement divisés et que les limites de décodage sont appliquées.

Rédigé par le modèle d'indexation à partir du texte de l'issue.