fix(ui): poll for out-of-band email confirmation

An email link/code can be confirmed out of band: the recipient taps the
one-tap link in the email, which confirms in another browser/session. The
backend already publishes a `notify` `profile` re-fetch signal for this
(handlers_auth.go handleEmailConfirmLink), and the client re-fetches on it.

But the live stream is single-shot with no replay: a Mini App backgrounded
while the user is in their mail app tapping the link drops the stream and
misses the event (the gateway hub has no subscriber to deliver to), and the
reconnect on foreground does not re-sync — so the open code form stayed
until a manual reload. On Telegram Desktop the app is never backgrounded,
so the push works and there was no bug.

Add a client-side fallback: while an add-email confirmation is pending
(a code was sent, no email yet), poll `profile.get` on a 4s interval and on
foreground regain until the address lands; the effect stops as soon as the
email appears. The live push still updates instantly when foregrounded —
this only covers the backgrounded-miss gap.

Tests: a mock e2e attaches the email WITHOUT emitting a live event (new
window.__mock.clearEmail / confirmEmailOutOfBand seams), so it exercises the
poll, not the push, and asserts the code form collapses into the email row.
Docs: ARCHITECTURE.md §10 notes the single-shot gap + the poll fallback.

docs/ARCHITECTURE.md

@@ -983,7 +983,10 @@ and the open client re-fetches `profile.get` to show or hide the banner in place
 edits take effect on the next `profile.get` (open/reconnect/foreground), not mid-session. The same
 mechanism carries a **`profile`** sub-kind — a payload-free re-fetch signal emitted when a viewer's
 own account changed out of band (an email confirmed through the one-tap deeplink opened in another
-browser), so an open in-app session reflects it at once.
+browser), so an open in-app session reflects it at once. The live stream is single-shot with no
+replay, so a **backgrounded Mini App** — suspended while the user is in their mail app tapping the
+link — misses the event; while an add-email confirmation is pending the client therefore also
+**polls `profile.get`** (and on foreground regain) as a fallback until the address lands.
 
 > A single `app.load` bootstrap aggregator (collapsing `profile.get` + lobby + badge fetches into
 > one round-trip) was **considered and deferred**: client↔gateway is HTTP/2 (h2c), so the bootstrap