Pagination data loss and limit boundary issues in read command #363

Currently, the read command uses a simplified messages.slice(-options.limit) approach to display the most recent messages (introduced in PR #356). While this correctly fixes the message ordering, it introduces a few pagination bugs and edge cases that need to be addressed.

1. Cursor Skipping (Data Loss During Pagination)

When a user requests a --limit smaller than the API's page size, the older messages in that fetched page are sliced off and hidden from the output. However, the command still returns the nextCursor from the entire fetched page.
Impact: If the user attempts to fetch older messages using this returned cursor, the API will start fetching from the end of the original page, permanently skipping the messages that were sliced off.
Reproduction:

# Assume an API page returns messages 0 to 10
instagram-cli read <thread-id> --limit 5
# Outputs newest 5 messages: 4, 3, 2, 1, 0. (Cursor points to message 10)

instagram-cli read <thread-id> --limit 5 --cursor <returned-cursor>
# Outputs: 15, 14, 13, 12, 11 (Messages 5~10 are completely skipped/lost)

2. Large Limits Ignored

The command currently executes a single API fetch. If a user inputs a limit larger than the API's single page size (e.g., --limit 50 while the page size is 20), the command will only ever output the 20 messages from that single fetch.

3. Zero or Negative Limits

Using --limit 0 currently evaluates to slice(-0), which is identical to slice(0) in JavaScript, returning the entire fetched page instead of an empty list.

Expected Behavior

1. Accurate Cursors: The returned cursor should precisely align with the oldest displayed message so that pagination is seamless and no messages are skipped.
2. Limit Fulfillment: If --limit is larger than a single page, the command should ideally auto-paginate in the background to fulfill the requested limit, or gracefully cap it.
3. Valid Bounds: --limit 0 should return no messages.

Proposed Solution

Implement a dedicated helper (e.g., collectReadMessages) for the read command to properly handle recursive page fetching to meet the requested limit, and dynamically calculate the correct cursor based on the boundaries of the messages actually shown to the user.