Split initialize() into the half that must run once and the half that retries

[cmdcolin]

Supersedes #826 and #827 — take this one or those two, not both. They guard the two once-only effects with flags; this removes the need for the flags by separating the once-only work from the retryable work, which is the actual defect.

initialize() did both kinds of work, and the single reaction calling it could only serve one: its dispose() sat behind both awaits, so the reaction stayed armed across two round trips with everything once-only already done — and what it tracks is self.role, which those very requests write, since a 403 from either takes getFetcher through removeToken()/setRole(). An expired token at startup, the ordinary case, therefore installed everything twice: a second "Admin" submenu (a menu contribution is appended to a log the root model replays on every open) and a second set of socket handlers (each is a fresh arrow function, so socket.io cannot recognize the repeat), which means every COMMON message reaching the change manager twice.

install() is the once-only half and loadInitialState() the retryable one, with a reaction each. The install reaction is synchronous, which is what makes "at most once" structural rather than a flag — dispose() runs in the same tick, so nothing can invalidate it in between — and addSocketListeners() moves to the top of install() because it is the only step that can throw, before it has registered anything, so a failed run leaves nothing installed and the reaction just stays armed.

Two consequences worth naming. roleNotificationSent is gone: it existed only to stop the no-access notification firing twice, which the synchronous reaction now prevents structurally.

And the socket handlers are registered ahead of both requests rather than between them, which needed one guard rather than none. Registering earlier means the first connect now lands in a handler instead of arriving while nothing is listening — but that is exactly the connect with no lastChangeSequenceNumber yet, because loadInitialState() is what sets it, and getMissingChanges() throws without one. Called as a void, that throw is an unhandled rejection on an ordinary startup. So the connect handler now returns early when there is no baseline, since before one exists there is by definition nothing to catch up on. The guard tests falsiness, matching getMissingChanges()' own condition, which also covers a server still at sequence 0 — where the same throw was reachable on every reconnect, before this PR and after it.

Not covered by tests either way — this path has none, and nothing in the repo instantiates an ApolloInternetAccount under test — so it wants a look from someone who owns the account model.

Verified with the repo's own toolchain: prettier returns the file unchanged, eslint --max-warnings 0 is clean, and tsc -p packages/jbrowse-plugin-apollo produces an error set identical to the branch point (none of them in this file). Also checked against jbrowse_5: this merges into it cleanly and typechecks there too.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SnSmtZPwNZR3764AJ16ZUL