(new): rich message support

(fix): runtime reliability
(tests): regression coverage
(doc): v1.1 release notes

AGENTS.md

@@ -60,6 +60,11 @@ Each exported godoc comment must:
 - avoid repeating the signature mechanically;
 - stay high-signal and informative.
 
+### Telegram API documentation and versions
+- When writing or updating godoc for Telegram Bot API types, fields, methods, or helpers, verify the description against the official [Telegram Bot API documentation](https://core.telegram.org/bots/api). Preserve relevant API semantics such as HTML equivalents, accepted ranges, formats, and optionality.
+- Add a `Since: Bot API X.Y` paragraph to each exported type, function, and method introduced in a specific Bot API version, using the established `tgapi` format.
+- Add an inline `// Since: Bot API X.Y` comment to an exported struct field only when its Bot API version differs from that of the containing struct. For example, if `InputRichMessage` was introduced in Bot API 10.1 and its `Media` field in Bot API 10.2, annotate only the `Media` field; do not repeat the struct's version on its original fields.
+
 ### Unexported declarations
 Unexported types, funcs, methods, vars, and consts should generally not have godoc-style comments unless there is a strong reason.
 
@@ -115,8 +120,8 @@ Prefer the repository’s documented commands. If multiple choices exist, use th
 
 ## Breaking changes policy
 - The agent must detect potential breaking changes before editing public APIs.
-- Breaking changes are forbidden unless the selected target version is a new major version.
-- If the requested change is breaking and the user did not bump the major version, the agent must stop and warn that the change is not allowed under the current version.
+- Breaking changes are forbidden unless the selected target version is a new major version, or it's necessary(i.e. fixing not working feature).
+- If the requested change is breaking, not necessary to fix a non-working feature, and the user did not bump the major version, the agent must stop and warn that the change is not allowed under the current version.
 - In that case, the agent must offer only these options:
   1. do not make the breaking change;
   2. introduce a backward-compatible alternative such as a new method, function, type, or struct, but only if that keeps the codebase reasonably small and clear;