fix(ui): load telegram-web-app.js dynamically with a timeout

The Telegram SDK was a render-blocking <script src="telegram.org/..."> in the
shared index.html shell, so it ran on every entry (/telegram/, /app/, native).
On a network that blocks telegram.org — common where Telegram itself reaches
users only over a proxy — the script hangs forever, stranding the whole page,
including the launch-diagnostic screen meant to surface exactly this failure.
This is the likely root cause of the Android "won't open" reports (all launch
methods fail identically; iOS on a different network works).

Remove the head <script> and load the SDK dynamically (lib/telegram.ts
loadTelegramSDK) with a 10s timeout, only on a Telegram entry (the /telegram/
path or a tgWebApp launch fragment). The SPA — served from our own reachable
origin — boots first and controls the load: on a block/error it falls through
to the diagnostic screen (reporting sdk: no) instead of hanging, and Retry
re-attempts. /app/ and the native build no longer touch telegram.org.

Pin the SDK to the version the official page recommends (?62) for the newer
client features the app already uses (fullscreen, safe areas, swipe guard).

Tests: loadTelegramSDK unit tests (present / error / timeout); an e2e that
aborts the script fetch and asserts the diagnostic still renders.

ui/src/lib/app.svelte.ts

@@ -15,6 +15,8 @@ import {
   collectTelegramDiag,
   type TelegramDiag,
   onTelegramPath,
+  hasLaunchFragment,
+  loadTelegramSDK,
   telegramColorScheme,
   telegramContentSafeAreaTop,
   telegramSafeAreaTop,
@@ -561,6 +563,12 @@ function applyTelegramChrome(launch: TelegramLaunch): void {
   telegramRequestFullscreen();
 }
 
+/** How long to wait for the dynamically loaded Telegram Mini App SDK before giving up and showing
+ *  the launch-error screen. A network that blocks telegram.org makes the script hang rather than
+ *  fail fast (a connection refusal resolves immediately via the script's error event), so this only
+ *  bounds a true hang; it is generous enough not to misfire on a slow but working network. */
+const TELEGRAM_SDK_TIMEOUT_MS = 10000;
+
 export async function bootstrap(): Promise<void> {
   const prefs = await loadPrefs();
   app.theme = prefs.theme ?? 'auto';
@@ -584,6 +592,13 @@ export async function bootstrap(): Promise<void> {
     window.visualViewport.addEventListener('scroll', syncViewportHeight);
   }
 
+  // Load the Telegram Mini App SDK dynamically, with a timeout, on a Telegram entry — it is no
+  // longer a render-blocking <script> in index.html, so a network that blocks telegram.org (common
+  // where Telegram itself reaches users only over a proxy) cannot hang the page and strand the app
+  // or the diagnostic screen below. Skipped on a plain web / native entry, which never needs it.
+  if (onTelegramPath() || hasLaunchFragment()) {
+    await loadTelegramSDK(TELEGRAM_SDK_TIMEOUT_MS);
+  }
   // Telegram Mini App launch: apply the platform theme, authenticate via initData, and route any
   // deep-link start parameter. On the dedicated /telegram/ entry without sign-in data (no/empty
   // initData — outside Telegram, or a Mini App launch that delivered none, as seen on some Android
@@ -675,6 +690,8 @@ export async function retryTelegramBoot(): Promise<void> {
  * so a reload could discard the very data we are waiting for.
  */
 export async function retryTelegramLaunch(): Promise<void> {
+  // Re-attempt the SDK load — the network may have recovered since the launch-error screen showed.
+  await loadTelegramSDK(TELEGRAM_SDK_TIMEOUT_MS);
   if (!insideTelegram()) {
     app.launchError = collectTelegramDiag();
     return;