[GeneWang1226]

Opening a chat containing formatted text after emoji can crash the TUI with a slice-bounds panic. Telegram entity offsets count UTF-16 code units, but the Markdown and ANSI renderers used them directly as rune indexes.

This PR converts entity ranges to rune boundaries before slicing and skips nil, invalid, overflowing, or split-surrogate ranges. The flat renderers retain enclosing formatting for overlapping ranges so message text is emitted once.

It also fixes issues found while exercising the REST API:

• Truncate the previews shared by REST and MCP at 80 Unicode characters, preserving valid UTF-8 for Chinese text and emoji.
• Validate numeric query parameters before converting to Telegram's signed 32-bit fields. Invalid or nonpositive limits return HTTP 400; positive limits above 100 remain capped at 100. Chat IDs stay 64-bit, and negative relative history offsets remain valid.
• Require exactly one JSON request value, rejecting trailing garbage or additional values before a Telegram operation is called. Trailing whitespace remains valid.
• Document these API rules and keep the interactive login example in the foreground, using the separate API/MCP session.

Regression tests cover supplementary Unicode characters, malformed and overlapping entity ranges, preview boundaries, service messages, JSON round trips, numeric overflow, and trailing request data.

Validation:

• go test -p=1 ./...
• go vet -p=1 ./...
• gofmt -l . (no output)
• Read-only API smoke tests against a supergroup, on both the original and fixed binaries: three pages of 100 messages with no duplicate IDs, supplementary Unicode text, service/media messages, and two polling requests. Malformed IDs and queries returned the expected 400/404 responses, and the server remained responsive.
• Confirmed that the original limit=4294967297 request silently returned one message; the fixed API returns HTTP 400. Send/edit operations were validated with local tests.