[bug] macos: mlx.metallib in Contents/MacOS/ invalidates bundle signature, keychain prompt every launch and macos: WAL backlog triggers db_wedge relaunch loop on large db (63GB)

screenpipe 2.7.28 (macOS, arm64) — two issues

Issue 1: mlx.metallib in Contents/MacOS/ breaks the bundle signature → keychain prompt on every launch

Contents/MacOS/mlx.metallib (88 MB) is a data blob, but macOS treats everything in Contents/MacOS/ as code requiring its own signature. It is sealed in CodeResources but is not itself signed, so the whole bundle fails validation:

$ codesign --verify --strict /Applications/screenpipe.app
/Applications/screenpipe.app: code object is not signed at all
In subcomponent: /Applications/screenpipe.app/Contents/MacOS/mlx.metallib

$ spctl --assess --type execute --verbose=4 /Applications/screenpipe.app
/Applications/screenpipe.app: rejected
source=no usable signature

The bundle does carry a valid Developer ID cert (Developer ID Application: Louis Beaumont (######)), but it does not validate.

Impact: keychain ACLs match on verified code identity. Because macOS cannot validate the app, the ACL for the login-keychain item com.screenpipe.app / store-encryption-key never matches, so the user is prompted for their keychain password on every launch and "Always Allow" cannot stick. This compounds with Issue 2, which relaunches the app automatically ~2x/day.

Suggested fix: move mlx.metallib to Contents/Resources/ (or any non-MacOS/ location) before signing.

Issue 2: WAL backlog triggers a db_wedge restart loop on large databases

Database: 63 GB, on an APFS external volume with 819 GB free (not a disk-space issue). journal_mode=wal, page_size=4096, wal_autocheckpoint=1000.

Occurs ~2x/day, beginning with the 2.7.28 update (0 occurrences on 2.7.x prior builds):

WARN screenpipe_app::recording::db_wedge: database lifecycle recovery requested —
  restarting recording to rebuild all DB pools + the shared WAL-index
  reason=WalBacklog { pending_pages: 41295, log_pages: 42241, checkpointed_pages: 946 }
WARN screenpipe_db::db::setup: write pool acquire connection error (attempt 1/3),
  retrying: attempted to acquire a connection on a closed pool
ERROR screenpipe_app::recording::db_wedge: db wedge recovery: server shutdown exceeded 15s;
  waiting before relaunch to release SQLite owners
ERROR screenpipe_app::health: boot phase → error: database unavailable; recording interrupted
INFO  screenpipe_app::process_exit: safe relaunch requested: DB owner shutdown incomplete
INFO  screenpipe_app::process_exit: safe relaunch: spawned replacement screenpipe-app (pid ...)
INFO  screenpipe_app::process_exit: Force-exiting process with status 0

Only 946 of 42,241 WAL pages checkpointed — autocheckpoint (1000 pages) is being starved, almost certainly by long-running readers holding the DB open. sqlx confirms these exist:

WARN sqlx::query: slow statement: execution time exceeded alert threshold
  db.statement="SELECT f.id, f.timestamp, f.offset_index, …"

Recording is interrupted each time. Also visible during the wedge: retention eviction fails against the closed pool (still working through data ~6 months old), and audio transcription backs up (47 chunks pending, oldest 6589s).

Questions: should wal_autocheckpoint scale with DB size? Is there a path to checkpoint without a full server shutdown, or to bound reader lifetime so wal_checkpoint(RESTART/TRUNCATE) can complete?

Environment

• macOS 25.6.0 (Darwin), Apple Silicon
• screenpipe 2.7.28, bundle id screenpi.pe
• Data dir on external APFS volume; DB 63 GB, dir 109 GB