Headless server: e2ee/verification succeeds but WhatsApp account never loads into app-level index (accounts=0, chats list empty) #29

Environment

• beeper-server (headless, no Electron/GUI) running under systemd on Linux, driven entirely via the beeper CLI (beeper status, beeper accounts, beeper chats list, beeper verify, etc.)
• Server build 4.3.23 (latest at time of investigation)
• One Matrix/Beeper account with one WhatsApp Cloud-linked account bridged through it

Symptom

After getting E2EE fully initialized and the device verified, the WhatsApp account never transitions out of "unloaded" in the app-level indexer, so chats list / messages return nothing even though the underlying Matrix sync is clearly healthy and growing.

Timeline / diagnostics

1. Initial blocker: e2ee.initialized stuck false for weeks despite verified: true and all 5 E2EE secrets present (masterKey, selfSigningKey, userSigningKey, megolmBackupKey, recoveryKey). Root cause turned out to be a corrupt local crypto store. Fix: stop the server, back up the profile dir, rm -rf the profile, beeper install server, restart, re-auth via email code. e2ee.initialized then correctly flips to true on the fresh profile.
2. Re-verification gotcha: after the wipe, SAS/emoji verification had to be redone against a new device id, and the verification prompt did not reliably surface on the paired phone/desktop. Root cause appears to have been a stale duplicate "Beeper Server (Linux)" device entry left over from the wiped profile, still marked verified. Logging out all devices from Beeper Desktop → Settings → Devices (which also force-logs-out the server) cleared it. After re-login + beeper verify -t server (note: beeper verify sas 409s with "not available in the current app state" — the bare verify command is what worked), the emoji-verification prompt finally appeared, was confirmed, and the server reached verified: true, secrets 5/5, firstSyncDone: true, state ready.
3. Remaining bug: even with the account fully verified and Matrix sync clearly healthy (index.db thread count growing steadily across days, e.g. ~1146 → 1522 → 1540+, with mx_room_state / mx_room_messages populated in the raw account DB), the WhatsApp account itself never loads into the indexer:

• index.db.accounts = 0 (permanently, checked repeatedly over multiple days)
• index.db.messages = 0
• Server log repeats: [syncEventsToAccount] queued N events for unloaded account whatsapp
• beeper chats list → "No chats matched"
• beeper bridges reports the WhatsApp bridge as connected
• beeper accounts lists the WhatsApp account as present
• So "connected" / "present" per bridges / accounts does not mean usable — the only reliable signal we found is chats list actually returning rows, which it never does.

1. Restarting the server while in this state is counterproductive: it drops the state from ready back to initializing and does not recover even after 20+ minutes of soaking — reproduced twice, on separate days.

Ask

• Is there a known issue where a bridged account's Matrix-side sync completes but the account is never loaded into the app-level SQLite index (index.db.accounts)?
• Is there a CLI/API way to force a reload of one specific account into the index without a full profile wipe?
• Happy to pull more beeper status --json output / server logs if that helps narrow it down.

This was raised with Beeper support by email first; they asked us to open an issue here with the technical detail, hence this report.