Filter notify backend logs from SQLite log sink

[th317erd]

Summary

Fixes #11.

This prevents the SQLite log sink from persisting raw notify backend TRACE/DEBUG messages such as:

• inotify event: ...
• adding inotify watch: ...
• removing inotify watch: ...
• FSEvent: ...
• kqueue event: ...
• Windows backend Event: path = ...

These messages are emitted through the log compatibility target by notify itself. In Codext, AuthWatch watches the top-level CODEX_HOME directory, and the SQLite log DB normally lives in CODEX_HOME. That can create a self-amplifying loop:

1. Codext writes a log row.
2. SQLite updates logs_2.sqlite-wal.
3. The CODEX_HOME watcher sees the WAL change.
4. notify emits a raw TRACE log for the file event.
5. The SQLite log sink persists that TRACE row.
6. SQLite updates the WAL again.

The fix keeps normal application logs intact, including unrelated target="log" TRACE rows, but drops low-level file-watch backend noise before it reaches the SQLite log DB.

Notes

The existing opentelemetry_sdk TRACE/DEBUG filter is preserved. This patch moves filtering after message extraction so the sink can identify specific notify backend messages.

Testing

cargo test -p codex-state sqlite_sink_drops_low_level_notify_logs --lib
cargo test -p codex-state sqlite_sink_drops_low_level_opentelemetry_sdk_logs --lib
cargo test -p codex-state --lib
cargo build -p codex-cli

I also ran a manual default-path retest with the patched binary:

• Removed the temporary sqlite_home workaround so SQLite returned to ~/.codex-work.
• Confirmed the patched process had ~/.codex-work/logs_2.sqlite-wal open.
• Created, modified, and removed 80 disposable top-level files in ~/.codex-work.
• Confirmed WAL size and bad-row counts did not increase.