Fix event-store Bandit baseline

[brainx]

Summary

• replace dynamic event-list SQL assembly with one fixed statement while keeping cursor pagination, ordering, limit handling, and all four filters parameterized
• isolate subscriber exceptions at the post-commit callback boundary and emit only a fixed, data-free warning so later subscribers still run
• add focused regressions for combined filtering and pagination, injection-shaped filter input, persisted-event integrity, subscriber continuation, and secret-safe failure handling

Scope

This is a focused prerequisite for #1. It does not modify or replace that compatibility pull request and does not change Zeus compatibility, OpenAPI fixtures, Kimi support, versions, or documentation.

Verification

• .venv/bin/python -m unittest tests.test_events — 6 tests passed
• .venv/bin/bandit -r olymp — no issues identified; zero lines skipped and zero suppressions
• sh scripts/repo_check.sh — passed; 197 tests, 85% coverage, formatting, Ruff, mypy, Bandit, lifecycle smoke, and repository scans
• sh scripts/test.sh — 197 tests passed with 85% coverage
• git diff --check — passed

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7b8f0037ec

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restore the rowid seek for cursor pagination

When GET /events or GET /runs/{run_id}/events supplies a non-null after_event_id, wrapping the primary-key predicate in ? IS NULL OR ... prevents SQLite from seeking by rowid: EXPLAIN QUERY PLAN reports SCAN events here, whereas the previous event_id > ? predicate reports SEARCH events USING INTEGER PRIMARY KEY (rowid>?). Consequently, every cursor request scans all events preceding the cursor, making repeated polling increasingly expensive as this append-only ledger grows; select a fixed statement containing a direct event_id > ? predicate when a cursor is present while continuing to bind all filter values.

Useful? React with 👍 / 👎.