fix: correctness batch from the second review

[SiteRelEnby]

Second of three PRs from the latest review (security batch is #33; self-hosting + CI is next). Seven
independent bugs, none of which needed a user to hit them first.

Registration cannot resend its verification email

register() holds the new tokens in ViewModel fields only, so isLoggedIn stays false until the email
is verified. But it never set authInterceptor.pendingToken, which the login path does set. Since
/v1/auth/resend-verification is authenticated, "Resend Email" straight after registering went out with
no bearer and 401d - and runCatching { api.resendVerification() } with no onFailure swallowed it, so
the UI cheerfully claimed the mail had been re-sent.

Set pendingToken at registration, and report the result. AwaitingEmailVerification is now a data class
carrying its own error / resent, because routing a resend failure through AuthUiState.Error would
have dropped the user back to the login form (the step selector only shows the verify step while the state
is AwaitingEmailVerification).

A failed history delete traps you in a dialog

onDismissRequest = { },                                        // back / scrim: dead
confirmButton = { TextButton(onClick = { viewModel.loadInitial() }) { Text("OK") } }   // never clears deleteError

Nothing ever set deleteError back to null except a successful delete, which you cannot perform while a
modal is up. Added clearDeleteError().

Backup download lost across the file picker

pendingDownloadJobId was a plain remember held across the SAF CreateDocument round trip. That picker
is a separate activity, so ours can be recreated behind it; on return the id is null, the if (uri != null && jobId != null) guard silently drops the download, and the user gets nothing after picking a location.
rememberSaveable.

Relationships: one failed load poisons the node

if (loadedFor == scope to nodeId) return
loadedFor = scope to nodeId        // set BEFORE the request

Latched before the load ran and never cleared on failure, so a single offline load meant that member or
group could never load relationships again for the life of the ViewModel. Latch on success only, add a
Retry. The post-mutation reload also dropped its error, showing a stale list after a save that actually
worked; it now says "Saved, but couldn`t refresh the list".

Relationship graph can render the wrong scope

No generation guard: tap Members then Groups, and if the members response lands second it writes itself
into state while scope is still "groups". Cancel the in-flight request and clear the stale graph.

Widgets can be killed mid-refresh

All six receivers did CoroutineScope(Dispatchers.IO).launch { ... } from onUpdate. Once onUpdate
returns the receiver is done and the process is killable, so a network refresh can be cut off and the
widget just stays stale. Shared refreshWidgets() helper: goAsync() to hold the broadcast open,
finish() in a finally, and an 8s bound so a hung refresh gets dropped rather than turning into an ANR
(the broadcast deadline is 10s foreground / 60s background).

JSON export was buffered, not streamed

/v1/export had no @Streaming. Retrofit therefore calls body().bytes() internally, so the callers byteStream().copyTo(output)- which *looks* like streaming, and whose KDoc says "streamed straight into [uri]" - was copying from a byte array already sitting in the heap. Large system, low-heap device, OOM. The zip download already had@Streaming`; added it to the JSON export and to the admin dossier export.

Verification

• :app:assemblePlayRelease :app:testPlayReleaseUnitTest green.
• Device pass worth doing on: register a fresh account and hit Resend; force a history delete failure
  (airplane mode) and dismiss the dialog; rotate during the backup file picker; open a member with the
  server unreachable and hit Retry; flip the graph tabs quickly.

Deferred to follow-ups

• The graphs force simulation is O(n^2) per step for up to 600 steps, and it runs on the main thread via withFrameNanos`. Correctness fix is here; moving it off the main thread (and/or Barnes-Hut) is its own PR.
• Channel / reminder editor drafts are held in plain ViewModel state and are lost on process death
  (CreateChannelScreen loses its form on a plain rotation). Separate PR.