fix: report MTProto schema drift instead of a generic error code

[artgas1]

Problem

When Telegram sends an object whose constructor the installed Telethon schema does not know, Telethon raises TypeNotFoundError. Right now log_and_format_error swallows it and the user sees:

An error occurred (code: CHAT-ERR-418). Check mcp_errors.log for details.

That is indistinguishable from "no such user/chat" — and it sends debugging in exactly the wrong direction.

Why this one deserves a named message

Schema drift does not fail cleanly. An unknown constructor desynchronises the whole read buffer, so the failure is partial and looks arbitrary: in our case list_chats, get_common_chats, resolve_username and get_full_user were failing while get_chats, search_contacts, list_messages and send_message kept working normally.

Two things made it worse:

• Resolving a username failed, so the obvious reading was "that account does not exist". It did exist — the raw bytes in mcp_errors.log contained the person's name and username in plain text, meaning the data had arrived and only parsing had failed.
• The constructor id in the error was not in any schema (we checked the installed one, the frozen v1 branch, and the current Telegram Desktop api.tl), because it is garbage read from the desynchronised stream. So searching for it leads nowhere either.

Root cause in our case: the installed Telethon was built for LAYER 227 while the server had moved to 228, where the user constructor changed (0x31774388 → 0xb1b8cc83).

Change

TypeNotFoundError now returns a message that names the condition, states that the data arrived and only parsing failed, and points at the fix. Every other error keeps the existing generic format — the helper's behaviour is unchanged for them.

The telethon import is done lazily inside a helper and guarded, so the module does not gain a hard import-time dependency.

Tests

tests/test_schema_drift.py covers both branches.

The new test was first run against a sabotaged implementation (the branch disabled) and fails there, so it can actually catch a regression rather than passing vacuously. Full suite green.

---

Separately we needed to fix the drift, not just report it, and did so by regenerating Telethon's TL classes against the current layer. That part is more invasive (it vendors a schema and the generator), so I'm not proposing it here — happy to open it as a second PR if you'd find it useful.