Wear OS: a dictation can sit on "Transcribing…" for six minutes, with no elapsed time and no way to cancel

[DevEmperor]

Reported by email (Tin Rudnicki, Galaxy Watch 7, fresh install, the app's own Try it): after
Stop & transcribe the watch sits on "Transcribing…" and, in his words, "nothing happened" — he
assumed a poor connection, went home, and got the same thing.

It is not hung. It is waiting, for far longer than anybody will wait, with nothing on screen that
says so. Why the phone never answers him is a separate question and still open; this issue is that
six silent minutes is the wrong answer to it whatever the cause.

The arithmetic

WearTranscription.tether wraps the wait for the phone's reply in
withTimeout(TRANSCRIBE_TIMEOUT_MS = 120_000). That timeout throws a TimeoutCancellationException,
which is an Exception, so tetherWithRetry's catch (e: Exception) treats it as a transport
hiccup and tries again — TETHER_ATTEMPTS = 3, with 0.5 s and 1.0 s between:

120 s + 0.5 s + 120 s + 1.0 s + 120 s  =  361.5 s  ≈  6 minutes

Only then does the standalone fallback start, if a key was synced — and that is
executeForBody(maxRetries = 3), i.e. up to four calls at the default 120 s callTimeout with 3 s
between them, another ~8 minutes. Worst case end to end is about a quarter of an hour.

And nothing says so

• The mic button shows a CircularProgressIndicator and the status line reads "Transcribing…". That
  is the whole of it.
• ElapsedTimer is already written and sits three lines above — inside if (recording), so it never
  appears for the wait that actually needs it.
• The cancel/pause row is likewise if (recording) only, and the mic button is enabled = !busy. So
  once transcription starts there is no way to stop it short of leaving the field.
• In the app's Try it chip the transcribing state is a label and nothing else.

The phone has had both halves of this for a while: #355 shows the elapsed seconds, #354 put a real
timeout on the work. The watch got neither. DictateSyncedSettings also carries no timeout field, so
the phone's Request timeout setting does not reach either of the watch's two legs.

What to change

1. Show the elapsed seconds while transcribing and rewording — reuse ElapsedTimer, which is already
   there and already themed.
2. Let a transcription be cancelled from the watch, the way a recording can be.
3. Reconsider three full 120 s attempts. A retry earns its keep after a transport error — the
   channel failing to open, the stream breaking — which is what Wear OS: "Transcription failed" on Pixel Watch (tethered, OpenAI gpt-4o-mini-transcribe) — Try-it and keyboard #218 added it for, and those fail
   fast. A response timeout is different: two minutes of silence from a phone that accepted the audio
   is not a hiccup, and repeating it twice more only multiplies the wait. Either treat a full-length
   timeout as terminal, or make the tether wait much shorter than the provider call it is waiting on.
4. Sync the phone's Request timeout to the watch and use it on both legs, so a user who shortens it
   there is not still waiting minutes here.

Related

#218 fixed the phone-side causes of a lost answer (service torn down mid-request, fire-and-forget
response, no transport retries) and made the real error reach the watch. What it did not do is make
the waiting itself visible or interruptible — which is what this reporter is looking at.