feat(telegram): unique chat binding and numeric measurement capture

Two related changes to the Telegram bot's data path.

One chat ⇄ one account. `User.telegramChatId` is now UNIQUE (migration
0189, defensive pre-clean of any pre-existing duplicate binding). The
inbound webhook resolves the user from the chat id, so a chat shared
across two accounts would route a reply or button tap ambiguously. The
index is over a nullable column, so an unlinked account (null chat id)
never collides — only two accounts binding the same non-null chat id are
rejected.

Numeric measurement capture. A numeric reply to a measurement reminder is
now captured as a Measurement (`source = TELEGRAM`, added to the enum in
0189). On "Erledigt" for a reminder that names a single-value metric, the
bot offers an optional value prompt via force_reply; a numeric reply is
written through the shared `logTelegramMeasurement` helper — same range
guard, canonical unit, cache + rollup refresh as the manual route. The
reply binds to the reminder and user through a TelegramPromptContext keyed
on the prompt message id (the same strict chat/message binding the
mood-note path uses); the userId is never read from the payload. Comma
decimals are tolerated; non-numeric and out-of-range replies get a calm
hint and write nothing; the reply self-cleans on the ~30-min sweep. Blood
pressure (two values) is out of scope for the single-numeric path and
keeps its satisfy-only flow.

src/lib/validations/measurement.ts

@@ -177,6 +177,13 @@ export const measurementSourceEnum = z.enum([
   // path), exactly like WHOOP/FITBIT. Part of this enum so the read/response
   // shapes (and the iOS decoder) can decode the rows it surfaces.
   "OURA",
+  // v1.19.2 — Telegram numeric-reply capture. A reply to a measurement
+  // reminder is written server-side from the chat-bound webhook (not the
+  // cookie/Bearer client write path), so it carries its own source label.
+  // Part of this enum so the read/response shapes (and the iOS decoder) can
+  // decode the rows it surfaces; the client-facing write surfaces still
+  // reject it (see `WRITABLE_MEASUREMENT_SOURCES` + the batch allowlist).
+  "TELEGRAM",
 ]);
 
 /**