Every `logSyncAttempt` call lived inside `handle()`, which is exactly what an
out-of-band death skips — so a connection's own history showed no trace of the
most common way this job dies. One prod connection has 66 job failures and 3
sync-log rows. That gap is why the first pass of this branch mis-attributed the
stranding to timeouts: the evidence was only in `failed_jobs`.
`duration_ms` becomes nullable at the call site rather than being faked to 0,
because nobody timed the attempt.
The copy changes too. `failed()` wrote "An unexpected error occurred during sync.
Please try again later." — handing our own infrastructure to the user as an
action — while the classified-transient path already promised "we will try
syncing again later" for the same situation. Every message this method writes
describes an out-of-band death, so it now says so and the next scheduled cycle
picks the connection back up on its own.
e0481df497