remote-control should recover from a corrupt logs_2.sqlite instead of failing readiness

What happened

codex remote-control failed to become ready because one local state database, logs_2.sqlite, was corrupt. The systemd service still appeared active, but the remote-control app-server never became available to the mobile client.

The CLI error was:

Starting app-server with remote control enabled...
Error: foreground app-server exited before remote control became ready

Caused by:
    failed to initialize sqlite state runtime under ~/.codex: failed to initialize state runtime at ~/.codex: error returned from database: (code: 26) file is not a database

The main thread/session database was healthy:

sqlite3 ~/.codex/state_5.sqlite 'PRAGMA integrity_check;'
# ok

But the log database was not a valid SQLite database:

file ~/.codex/logs_2.sqlite
# data

sqlite3 ~/.codex/logs_2.sqlite 'PRAGMA integrity_check;'
# Error: in prepare, file is not a database (26)

Renaming the corrupt log DB and restarting remote-control fixed the problem:

mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.corrupt-$(date +%Y%m%d-%H%M%S)
systemctl --user restart codex-remote-control.service

After restart, Codex recreated logs_2.sqlite, integrity check returned ok, and remote-control became available again:

This machine is available for remote control as <host>.
Press Ctrl-C to stop.

Expected behavior

If logs_2.sqlite is app-owned/rebuildable log state, codex remote-control / app-server startup should not fail permanently when only that database is corrupt. It could quarantine the corrupt file, recreate the log database, emit a warning, and continue startup.

For example:

warning: ~/.codex/logs_2.sqlite is corrupt; moved to ~/.codex/logs_2.sqlite.corrupt-<timestamp> and recreated it

Why this matters

Remote-control is commonly used as a headless/background process, sometimes on remote Linux/HPC/SSH machines with network-mounted home directories. A corrupt rebuildable log database currently makes the service look alive while remote access is unavailable, and the mobile client cannot recover it because remote-control never becomes ready.

Environment

• Codex CLI: 0.133.0
• Command: codex remote-control
• OS: Linux remote/HPC host
• ~/.codex was on a network-backed home directory

Suggested fix

During state runtime initialization, distinguish required state databases from rebuildable log/event databases. If logs_2.sqlite fails with SQLite code 26 (SQLITE_NOTADB) or equivalent corruption/open errors, move it aside with a timestamped .corrupt-* suffix and recreate it. The startup path should still fail for non-rebuildable databases such as the main thread/session state unless there is a safe recovery path.