Legacy-cursor reset never converges (rcursor computed from original cursor)

Severity: high (correctness bug).

### Summary

The DB layer treats a cursor > 10^12 (pre-`seq` microsecond timestamps) as 0 (`crates/node/src/database/sqlite/mod.rs:160-166`), but the gRPC handler computes the response cursor from the **original** request cursor: `let mut rcursor = cursor;` then `max` with the returned seqs (`crates/node/src/node/grpc/mod.rs:261`).

### Impact

A client sending a legacy cursor (~1.7e15) gets the oldest 500 notes plus `rcursor ≈ 1.7e15`; its next fetch sends the same cursor, gets the same 500 notes again — forever. It never advances past the first batch and permanently re-downloads duplicates.

### Recommendation

Perform the legacy reset in the handler (or return the effective cursor from the DB layer) so `rcursor = max(effective_cursor, max_seq)`.

Related: #101.

---
Part of #114.