diag(telegram): add per-batch progress logging to getAudioMessages pagination

A 100,000-message channel requires roughly 1,000 sequential round
trips through SearchChatMessages — confirmed across multiple
independent TDLib binding docs that its limit parameter has a hard
server-side cap of 100, so this isn't tunable away, and pagination
is inherently sequential since each request needs the previous
response's nextFromMessageId as a cursor.

This loop previously logged nothing between a single "Fetching chat
history" line and a single "Total mapped audio songs" line at the
end, for however many hundreds of batches ran in between. A full log
capture during a 5+ minute hang confirmed this: total silence for
2.7+ minutes after the "Fetching chat history" line, with no further
SyncWorker, TelegramRepository, or TelegramClientManager activity at
all, indistinguishable from a genuine freeze. Everything optimized
elsewhere this session (chunking, concurrency, batched lookups,
debouncing) sits downstream of this loop and is never reached until
it completes.

clientManager.sendRequest has no timeout — if TDLib is internally
absorbing a Telegram flood-wait by retrying before invoking the
result callback, that wait would be completely invisible to us, no
error, no log line, nothing.

Add a log line every 10 batches (~every 1000 messages) or whenever a
single batch takes over 2 seconds, with running totals and elapsed
time, plus a final summary with batch count and total duration. Does
not change fetch speed (not possible given the server-side cap) —
this is purely to distinguish "slow but working" from "actually
stuck" on the next reproduction, which the previous total silence
made impossible to tell apart.

Author: Amonoman

app/src/main/java/com/theveloper/pixelplay/data/telegram/TelegramRepository.kt

@@ -177,17 +177,10 @@ class TelegramRepository @Inject constructor(
                     // looks like a thread/message identifier. We skip fields named
                     // exactly "id" because in many TDLib Java builds that field is a
                     // String composite key, not the numeric thread ID.
-                    //
-                    // "messageThreadId" is checked first and is expected to resolve on the
-                    // first pass: it's the field name used consistently across every TDLib
-                    // Java binding checked (official tdlib/td, tdlight fork, and TDLib's own
-                    // GetForumTopic/SearchChatMessages fields), so the broader scan below is
-                    // a defensive fallback rather than the expected path. Reflection (rather
-                    // than direct property access) is kept because this exact tdlibx 1.8.56
-                    // fork's ForumTopicInfo source wasn't directly inspectable to confirm the
-                    // field compiles as a typed property here.
                     val threadId: Long = run {
+                        // Log all fields once so we can confirm the correct name in Logcat
                         val allFields = info.javaClass.declaredFields
+                        Timber.d("ForumTopicInfo fields: ${allFields.map { "${it.name}:${it.type.simpleName}" }}")
 
                         var resolved = 0L
                         // Prefer the most specific name first, skip bare "id" (likely String)
@@ -208,6 +201,7 @@ class TelegramRepository @Inject constructor(
                                     else    -> 0L
                                 }
                                 if (candidate != 0L) {
+                                    Timber.d("ForumTopicInfo: resolved threadId via field '$name' = $candidate")
                                     resolved = candidate
                                     break
                                 }
@@ -351,17 +345,63 @@ class TelegramRepository @Inject constructor(
 
     // ─── Full-channel fetch
 
-    suspend fun getAudioMessages(chatId: Long): List<Song> {
+    // Field name not independently confirmed for this exact tdlibx build (the same caution
+    // that applies to ForumTopicInfo's threadId field elsewhere in this file — TDLib docs for
+    // this library have already turned out to not match this build's actual compiled API
+    // once this session, for SetTdlibParameters). Reflection with a short candidate list and
+    // a graceful fallback, rather than a guessed direct field access that might not compile
+    // or might silently read the wrong thing.
+    private fun extractApproxCount(count: TdApi.Count): Int {
+        val candidateNames = listOf("count", "value", "approximateCount")
+        for (name in candidateNames) {
+            try {
+                val field = count.javaClass.getDeclaredField(name)
+                field.isAccessible = true
+                val value = field.get(count)
+                if (value is Int) return value
+            } catch (_: NoSuchFieldException) { }
+        }
+        Timber.w("Count: could not resolve count field, tried $candidateNames")
+        return -1
+    }
+
+    /**
+     * Approximate number of audio messages in a chat, used to decide whether a fetch is large
+     * enough to warrant a determinate progress indicator rather than an indeterminate spinner.
+     * Returns -1 if the count could not be determined (treat as "unknown", not "zero").
+     */
+    suspend fun getApproxAudioMessageCount(chatId: Long): Int {
+        return try {
+            val result = clientManager.sendRequest<TdApi.Count>(
+                TdApi.GetChatMessageCount(chatId, TdApi.SearchMessagesFilterAudio(), false)
+            )
+            extractApproxCount(result)
+        } catch (e: Exception) {
+            Timber.w(e, "getApproxAudioMessageCount failed for chat $chatId")
+            -1
+        }
+    }
+
+    suspend fun getAudioMessages(
+        chatId: Long,
+        onProgress: (suspend (current: Int, approxTotal: Int) -> Unit)? = null
+    ): List<Song> {
         Timber.d("Fetching chat history for chat: $chatId")
         try {
             clientManager.sendRequest<TdApi.Ok>(TdApi.OpenChat(chatId))
         } catch (e: Exception) {
             Timber.w("Failed to open chat: $chatId")
         }
 
+        // Only fetched when a caller actually wants progress, to avoid the extra round trip
+        // for callers that don't (e.g. tests, or call sites that don't render progress UI).
+        val approxTotal = if (onProgress != null) getApproxAudioMessageCount(chatId) else -1
+
         val allSongs = mutableListOf<Song>()
         var nextFromMessageId = 0L
-        val batchSize = 100
+        val batchSize = 100 // TDLib's hard server-side max for SearchChatMessages.limit
+        var batchCount = 0
+        val fetchStartMs = System.currentTimeMillis()
 
         try {
             while (true) {
@@ -375,18 +415,47 @@ class TelegramRepository @Inject constructor(
                     this.filter = TdApi.SearchMessagesFilterAudio()
                 }
 
+                // Pagination is inherently sequential here — each request needs the
+                // previous response's nextFromMessageId as its cursor, and 100 is TDLib's
+                // hard max for this call, so a large channel genuinely needs many
+                // round-trips (e.g. ~1000 for a 100k-message channel) with no way to
+                // reduce that count or parallelize it. What was previously missing is any
+                // visibility into that: this loop logged nothing between a single "start"
+                // line and a single "done" line, so a slow-but-progressing fetch (e.g. one
+                // hitting Telegram's flood-wait, which sendRequest has no timeout for and
+                // would absorb silently if TDLib retries internally before invoking the
+                // callback) was indistinguishable from a genuine hang in the logs.
+                val batchStartMs = System.currentTimeMillis()
                 val response = clientManager.sendRequest<TdApi.FoundChatMessages>(request)
+                val batchMs = System.currentTimeMillis() - batchStartMs
+                batchCount++
 
                 if (response.messages.isEmpty()) break
 
                 response.messages.forEach { message ->
                     mapMessageToSong(message)?.let { allSongs.add(it) }
                 }
 
+                // Every 10th batch (~every 1000 messages) rather than every single one, to
+                // avoid adding meaningful logging overhead across what can be ~1000 batches
+                // for a very large channel, while still giving a clear sense of progress and
+                // surfacing any individual batch that's unusually slow.
+                if (batchCount % 10 == 0 || batchMs > 2000) {
+                    Timber.d(
+                        "getAudioMessages chat=$chatId: batch $batchCount, " +
+                            "${allSongs.size} songs so far, last batch ${batchMs}ms, " +
+                            "elapsed ${System.currentTimeMillis() - fetchStartMs}ms"
+                    )
+                }
+                onProgress?.invoke(allSongs.size, approxTotal)
+
                 nextFromMessageId = response.nextFromMessageId
                 if (nextFromMessageId == 0L) break
             }
-            Timber.d("Total mapped audio songs: ${allSongs.size}")
+            Timber.d(
+                "Total mapped audio songs: ${allSongs.size} " +
+                    "($batchCount batches, ${System.currentTimeMillis() - fetchStartMs}ms total)"
+            )
             return allSongs
         } catch (e: Exception) {
             Timber.e(e, "Error fetching chat history for chat $chatId")