feat(sdk): page from a client, not only from curl

[glatinone]

feat(sdk): page from a client, not only from curl

The server gained offset on both listing endpoints and the pagination was
reachable only by hand. Every method in both SDKs returned just results, so a
caller had no way to ask for the next page: recall(query, owner, limit=5) could
only ever fetch the first five.

• Python recall / list_memories (sync and async) and Node recall /
  listMemories take offset, defaulted to 0, so existing calls are unchanged.
• Docstrings and both READMEs say what the caller needs to page correctly: a page
  shorter than limit is the last one, and the response's has_more is reachable
  through the underlying session/fetch for callers who want it explicitly. The
  methods keep returning the cells rather than changing to a dict, because a
  return-type change is a break and len(page) < limit is the convention every
  paginated API already uses.
• Tests assert on the request the client actually makes. The first version of the
  Node test built the request body inside the test and asserted on it - it would
  have passed with offset deleted from the client, which is worse than no test.
  Replaced with a captured fetch: recall with {offset: 10} has to put 10 in
  the body it sends, and listMemories has to put it in the query string. The
  Python tests do the same through the mocked httpx.AsyncClient / requests
  seam the existing suite already uses.

[glatinone]

Landed on master in the v0.1.0 chain: the branch was fast-forward merged as part of b940905..92b88ee and released as v0.1.0. Closing so the open list matches reality - the commits are in master, and the tag points at them.