[codex] add admin leaderboard submission listing

[msaroufim]

What changed

Adds an admin-only API endpoint to list all submissions for a leaderboard with stable metadata needed for manual cleanup and ID-by-ID deletion.

• adds GET /admin/leaderboards/{leaderboard_name}/submissions
• adds LeaderboardDB.get_leaderboard_submission_history(...)
• adds admin API test coverage for the new route

Why

The existing admin API could delete submissions by ID or delete all submissions for a user, but it did not expose a supported way to enumerate all submission IDs on a leaderboard first.

Impact

Admins can now:

• list submission IDs for a leaderboard
• inspect file name, user, timestamp, and done state
• use those IDs for explicit follow-up deletion flows

Validation

• ./.venv/bin/pytest tests/test_admin_api.py -q
• exercised the new endpoint locally against a real Postgres-backed app using a temporary database and seeded submissions

Notes

This PR only includes the endpoint, DB helper, and tests. It intentionally excludes unrelated local changes in the worktree.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
src/libkernelbot
leaderboard_db.py					1286-1318
utils.py
Project Total

This report was generated by python-coverage-comment-action

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e1e715e4b3

ℹ️ 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]

Return clamped pagination values in response

get_leaderboard_submission_history clamps limit to [1, 1000] and offset to >=0, but this handler echoes the raw query values, so the response metadata can disagree with what the DB actually applied (for example, limit=5000 returns at most 1000 rows while reporting limit: 5000, or offset=-10 reports -10 while querying from 0). This can break admin pagination clients that trust the returned limit/offset to compute the next page.

Useful? React with 👍 / 👎.