hive-matrix-mcp: bound each secondary retry, warn once per outage

Three follow-ups to argus's review of #5237:

- A down secondary's retry runs `restore` under RESTORE_TIMEOUT (2 min).
  Tries run one per tick on one future, so a restore that never resolved
  held back every other down account's retries for good; a try that
  outlasts the timeout now counts as a failure like any other.
- `client::build_and_restore` warns about a rejected token only for the
  primary, which exits right after. For a secondary it logs at debug: the
  retry loop already warns once per outage (`DownAccounts::failed` is news
  on the first failure and on a changed reason, and an account that came
  up starts afresh), so the extra warn repeated on every try.
- `a_secondary_that_comes_up_late_does_not_wipe_the_todos` runs the late
  bring-up in a child process of the test binary with HIVE_AGENT_SOCKET
  pointed at the test's listener. In-process the variable was unset, so a
  wipe placed back in the bring-up path was a no-op and the test passed.

New tests: a_second_rejection_in_a_row_does_not_warn_again (captured logs, alone
in a child process since tracing caches callsite interest process-wide;
a stub whoami answering M_UNKNOWN_TOKEN, the real build_and_restore),
a_failure_after_the_account_came_up_is_news_again, and
an_account_whose_restore_hangs_does_not_hold_back_the_others (paused time).

docs/agent-lifecycle/persistence.md

@@ -599,7 +599,9 @@ two-minute tick it tries again each secondary account that didn't come
 up — a declared account with no token yet, a token the homeserver
 rejected, or a homeserver that
 was down — waiting two minutes after its first failure and twice as long
-after each further one, up to sixteen minutes. One that comes up joins
+after each further one, up to sixteen minutes. It tries one account at a
+time and counts a try that hasn't finished after two minutes as a failure,
+so one hung account doesn't hold the others back. One that comes up joins
 the running daemon; the primary and the other accounts aren't
 restarted. The same token watcher also drives avatar setting: on a
 restart the daemon re-runs each account's bring-up, which sets the