Stop asking a session too fresh to answer about other logins

Signing in raised "Someone just got access to your messages!" right away,
and "Yes, it's me" answered with "For security reasons, you can't terminate
older sessions from a device that you've just connected."

Both halves come from the same place. The prompts are seeded by the
account.getAuthorizations sweep that runs on `user_auth` - which fires on
every start of a signed-in account, not only on a login - and the server
keeps `unconfirmed` on a session for authorization_autoconfirm_period
(7 days by default), so logins from days ago still carry it. On the account
this was found on, two did: 54 and 64 hours old. But the server also locks a
session out of reviewing any other one for its first 24 hours, so every
prompt raised in that window could only dead-end in that toast.

So the prompts now wait: while our own session is younger than
FRESH_AUTHORIZATION_PERIOD nothing is published, and a timer releases the
list once the window passes. Web A holds its bar back the same way. The list
itself is still stored and persisted - only its visibility moves.

The session's own age is taken from `date_created` of the `current` entry in
the sweep and persisted (state.currentAuthorizationDate), so a reload inside
the window does not bring the dead-end back. It cannot come from the
`user_auth` payload: a plain start stamps that one with the current time
(createManagers -> setUserAuth(userId)), which would hide every prompt
forever.

Two more things on the way:

  * the sweep no longer takes `pFlags.current`. The flag sits on the session
    row rather than on the viewer, so the session we run on can come back
    carrying it, and a device cannot answer about itself. tdesktop and
    Android sidestep this by never reading the flag from the session list at
    all, building their lists from updateNewAuthorization alone.

  * both error sites share getAuthorizationErrorLangKey, which matches any
    FRESH_* rather than the reset name alone - confirming is documented as
    FRESH_CHANGE_AUTHORIZATION_FORBIDDEN, yet answered with the reset one
    here.

A prompt restored from state now publishes its event too, so a consumer that
asked before the state was read no longer waits for the next change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>