README and intro docs still describe fetch_notes pagination as timestamp-based

### Problem

Two documentation entries still describe `fetch_notes` pagination as timestamp-based, but the current implementation uses the server-assigned monotonic `seq` cursor.

File evidence:
- `docs/src/index.md` says the node labels notes with an increasing cursor that is "currently a timestamp".
- `crates/node/README.md` says `fetch_notes()` uses pagination based on a timestamp.

The current implementation and external docs describe `seq`-based pagination instead:
- `docs/external/src/design.md` documents `FetchNotes` as `seq > cursor` ordered by `seq`.
- `crates/node/src/database/sqlite/mod.rs` filters by the SQLite `seq` column and only treats very large timestamp-like cursors as legacy values.

### Why this matters

Clients should persist and resend the cursor returned by the server. Timestamp-based wording is stale after the `seq` cursor migration and can lead implementers to infer the wrong cursor semantics.

### Suggested fix

Update the README and intro docs to describe `fetch_notes` pagination as based on the server-assigned `seq` cursor, and mention the legacy timestamp reset only where relevant.