fix(telegram): hidden text-link URLs reach the agent inline (#31071, salvage #74769)

[teknium1]

Summary

Telegram messages with hidden hyperlinks ("click here" with a text_link entity) now reach the agent with the URL inlined — previously the agent saw only the anchor text and could not follow or fetch the link (#31071).

Salvage of #74769 by @DreamyMoonMouse onto current main (clean cherry-pick, authorship preserved). Ported here from the weekly NanoClaw scout (nanocoai/nanoclaw#3283 fixes the same platform gap); an open community PR already covered it, so it is salvaged instead of reimplemented.

Changes

• plugins/platforms/telegram/adapter.py: new _expand_link_entities() — converts UTF-16 entity offsets to code-point indices (emoji/CJK-safe), appends (url) after each text_link anchor, idempotent on re-processing; wired into _build_message_event() (all text paths) plus both media-caption paths.
• tests/gateway/test_telegram_text_link_expansion.py: 13 tests — plain text, captions, emoji offsets, malformed entities, repeat processing.

Why this PR over #31075

#31075 (earlier, by @dskwe) targets gateway/platforms/telegram.py, which no longer exists after the adapter moved to plugins/platforms/telegram/; it also only covers 2 of the 3 ingestion paths. This branch cherry-picks #74769, which targets the current location and covers _build_message_event centrally. @dskwe was first to the bug — credit noted here.

Validation

	Before	After
text_link in DM text	agent sees "click here"	"click here (https://…)"
caption entities	URL lost	URL inlined
targeted tests	—	31 passed (expansion + caption/channel suites)

Source scout reference: nanocoai/nanoclaw#3283.

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 3f6c3ba — refactor(telegram): move text_link expansion to telegram_ent}

⚠️ Warnings

OSV vulnerability scan · View job

76 known vulnerabilities found in pinned dependencies.

• CVE-2026-83608 in package-lock.json
• CVE-2026-83608 in package-lock.json
• CVE-2026-84375 in package-lock.json
• CVE-2026-84375 in website/package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-85062 in package-lock.json
• CVE-2026-85062 in website/package-lock.json
• CVE-2026-83609 in package-lock.json
• CVE-2026-82417 in scripts/whatsapp-bridge/package-lock.json
• CVE-2026-82417 in website/package-lock.json
• CVE-2026-84369 in website/package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-75931 in package-lock.json
• CVE-2026-75931 in website/package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-71554 in uv.lock

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

---

debug info

CI timings

CI timings · View report · View job

Wall time 5m3s vs 5m33s (-9.0%). 9 job(s) slower, 4 faster, 1 unchanged.

• OS-specific tests / Windows-only tests: -32.0s
• OS-specific tests / macOS-only tests: -13.0s
• Check contributors / check-attribution: +8.0s
• Detect affected areas: +5.0s
• OSV scan / Scan lockfiles / osv-scan: +3.0s

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Well-executed fix with unusually complete tests — the UTF-16 offset conversion (plugins/platforms/telegram/adapter.py:9131-9140) handles the emoji/surrogate cases that usually break this class of change, malformed entities fail closed, and reverse-sorted insertion keeps offsets valid. Three small things:

1. plugins/platforms/telegram/adapter.py:9169-9172 — the idempotency guard expanded[end:].startswith(inline) misfires when a user genuinely writes anchor text immediately followed by the same parenthesized URL ("see тут (https://x.com)"): the real link entity is then silently dropped because the text looks pre-expanded. Rare, but since the comment claims repeated processing is the reason, a stronger discriminator would be checking that the char before end belongs to the anchor and the parenthetical wasn't part of any entity — or simply tracking processed update_ids upstream instead of shape-matching the text.

2. plugins/platforms/telegram/adapter.py:9964 / :9979 vs :10687 — media handlers expand the caption explicitly and then _build_message_event also expands it internally for the same message, so the caption runs through _expand_link_entities twice per observed media event. Harmless today (second pass hits the idempotency guard), but it means point 1's false-positive window is hit twice for media captions; passing the already-expanded text through, or expanding only at the _build_message_event layer, would remove the duplication.

3. plugins/platforms/telegram/adapter.py:9142-9143 — utf16_length recomputes a full scan per call; folding it into one pass with the index walk is trivial but honestly unnecessary at message sizes. Noting only so nobody "optimizes" the loop into subtle breakage.