feat: expose message read status when fetching IM messages

Feature request

Please expose the read status of IM messages when fetching or inspecting messages through lark-cli.

Motivation

Agent workflows often use lark-cli or related skills to pull Lark/Feishu messages for triage, summarization, or follow-up. Today there is no obvious way in the CLI output to tell whether a fetched message has already been read.

For automation, this matters because agents need to distinguish unread items from already-read context. Without read-state information, downstream workflows either over-process messages or have to rely on external UI/manual state.

Desired behavior

When fetching messages, include read-state metadata in the structured output where the underlying Lark API supports it. For example:

lark-cli im +messages --chat-id <chat_id> --include-read-status --as user
lark-cli im +message --message-id <message_id> --include-read-status --as user

The JSON output could include fields such as:

{
  "message_id": "...",
  "chat_id": "...",
  "read_status": "read",
  "is_read": true
}

Exact field names can follow existing lark-cli conventions and the Lark OpenAPI response shape.

Scope

This request is about reading/exposing message read status in CLI results. It is not asking for a command that marks messages or chats as read.

Why this matters

This would make message triage workflows much more reliable: fetch messages -> inspect read/unread state -> process only the relevant items or preserve that metadata for downstream automation.

Start with the lark-cli im +messages and im +message entry points and inspect the underlying Lark OpenAPI response shape for read-state fields. Determine how structured output and existing option conventions should expose that metadata, then verify both commands return it without adding mark-as-read behavior.