StreamNotes can silently drop notes for connected subscribers

Severity: high (correctness).

### Summary

Streaming is lossy even for well-behaved, connected clients. The per-tag cursor is advanced **before** delivery is attempted, and delivery only happens if a waker is currently registered for the subscriber.

### Evidence

- `crates/node/src/node/grpc/streaming.rs:220-226`: `update_timestamps` (cursor advance) runs before `forward_updates` (delivery).
- `streaming.rs:128-135`: a batch is only delivered to a sub if `self.wakers.remove(sub_id)` returns `Some` — otherwise it is skipped for that sub with no `try_send` into the buffer. On `try_send` failure the sub is evicted and the batch is lost.

### Impact

A subscriber whose waker message hasn't been processed yet (new sub between `AddSub` and its first `Waker`, or mid-repoll) misses that tick's notes with no error, and the cursor has already advanced, so they are never re-sent. For private notes (this service is the only carrier of `NoteDetails`) that is silent, unrecoverable loss.

### Recommendation

Advance the tag cursor only past notes actually enqueued to every subscriber (or track per-sub cursors); use the channel buffer regardless of waker registration; on eviction, end the stream with an explicit `Status` carrying the last delivered cursor (see the streaming-hardening issue).

Related: #96 (stream ignores cursor), #101.

---
Part of #114.