feat(pr): reconcile remote state after write actions, and never leave the window blank

[huhamhire]

Two related asynchronous-experience problems, both in the same family: an action completes, and the UI is left showing something that is no longer true.

1. Write actions do not settle synchronously

A merge or review verdict returns as soon as the remote accepts it, while the state the UI reads is recomputed asynchronously and lands seconds later:

• merge — the PR keeps reporting state: ''open'' and keeps coming back in the discovery list. The renderer fired a full poll the instant the merge returned, which is therefore guaranteed to read pre-merge state: a network round-trip across every connection, only to redraw the same list with the PR still in it. It then sat there until the next periodic sync.
• approve — mergeStatus.canMerge is a server-side verdict over approvals / builds / branch protection. An approval satisfying the last required rule flips it, but the remote recomputes only after the call returns, and nothing re-read it. The merge button stayed hidden until the next periodic sync.

Both actions now start a bounded backoff re-check in main (services/pr-post-action.ts): refresh that one PR on a growing delay until the expected change appears, broadcasting a new prs:changed event for the renderer to reload. Fire-and-forget, so the IPC never waits on the remote settling; past its window the periodic poll remains the backstop.

A confirmed merge archives that one PR directly, via a new Poller.archivePullRequest. The list filters on archivedAt rather than PR state, so a merged PR disappears only once archived — and running a whole poll tick for it would put every connection''s discovery fetch in front of the departure the user is waiting on. The departure a poll infers from absence is already established by the confirmed remote state, so it is asserted directly.

Living in main covers every entry point with one implementation: the buttons, the chat commands, and the CLI''s review write actions all share these controllers.

2. A renderer failure could leave the window permanently blank

Reported as: after a PR action, clicking around quickly turns the UI black, with no recovery. Nothing was watching at any level —

• main.tsx rendered <App/> with no boundary above it, so any error thrown while rendering unmounted the whole tree and emptied #root;
• main registered no webContents listeners, so a dead renderer process went unnoticed;
• and neither kind of crash reached meebox.log — the historical logs contain zero renderer records, which is why the report left nothing behind to diagnose.

Three layers, each covering what the others structurally cannot see:

1. Render-phase errors → a root ErrorBoundary with a full-window AppCrashScreen (retry / reload). The boundary now also relays the stack via log:write, since the renderer console is not written to file and a caught render error is not an uncaught window error either.
2. Failures before React mounts → boot-guard.ts, imported first so it is armed before any other module can throw. A module failing while it initializes takes down the entry before render() runs, leaving no React and thus no boundary; the guard paints a plain-DOM recovery screen, depending on no React, i18n or stylesheet, since each of those is a candidate cause.
3. Renderer process death → render-process-gone / did-fail-load in main, logged and reloaded with a bounded retry budget so a page that dies on load cannot spin in a reload loop. unresponsive is logged but deliberately not recovered: it usually resolves on its own, and reloading would discard in-flight state.

Also fixes a race in the same family, and in exactly the reported scenario: mergeSelectedPr compared the selection against the selectedId its callback had closed over, so selecting another PR while the merge round-trip was in flight cleared the PR the user had just opened.

Verification

• lint / typecheck / test / build all pass. New test covers archivePullRequest: a PR the remote still lists is not dropped by a tick but is by an explicit archive, and repeat / unknown-id calls are no-ops.
• Not exercised on a live app: verifying the merge path means actually merging a remote PR, and triggering the crash screens means running the desktop app under a deliberate fault — neither was done here. To self-check the containment, throw in any component in dev: the crash panel should replace the black screen, and meebox.log should gain a renderer render error:App line with the component stack.

The crash containment is deliberately containment, not a root-cause fix — the specific trigger for the black screen is still unknown. It will now surface itself: next reproduction leaves a panel on screen and a stack in the log.

🤖 Generated with Claude Code