issues: re-land the three session findings PR #1490 lost when it was closed

[BigSimmo]

Summary

Ledger-only. PR #1490 was closed unmerged, so none of its content reached main. These three findings existed nowhere durable and are re-landed here.

A note on how that went unnoticed: checking whether the rows had landed by id reported them present. They were not — main's #149 and #150 are unrelated rows (check:installed-lock-parity coverage, and CodeRabbit review-budget exhaustion) that happened to take those ids during a concurrent renumber. Only a content check showed the originals were absent. Ids allocated in parallel branches are not stable identifiers for "did my row land".

• #151 (new, P3) — corrects an incorrect claim I made repeatedly during the session: that CI could not be read at all. The PAT lacks Checks: read but has Actions: read, so gh api "repos/BigSimmo/Database/actions/runs?head_sha=<sha>" answers the question. What made this look like a hard wall is that GET /commits/:sha/status succeeds and returns total: 0 — this repo reports through Actions, not legacy statuses — so the permission gap presented as an absence of checks. The cost was real: two PRs were armed for auto-merge rather than merged, on the belief their hosted verdict was unknowable. For the record, issues: capture the unreadable-CI token, at-risk worktree work, and the unpushed hook fix #1490's head was CI/PR Policy/PR mergeability/SAST/Secret Scan all completed/success.

• #152 (new, P2) — the at-risk worktree inventory plus the four preservation snapshots (748ef018f, 5dbd9f965, b7eae51a4, d949859c3). Those commits exist on their branches but nothing recorded that they exist or why; that record was the unique content of the closed issues: capture the unreadable-CI token, at-risk worktree work, and the unpushed hook fix #1490. The largest is +395/−200 across 19 files including .github/workflows/ci.yml.

• #153 (archived) — the pre-commit hook aborting commits in worktrees that lack the sync script, resolved by PR fix(hooks): fail open when the inventory script is absent from the worktree #1494.

Verification

• npm run check:outstanding-issues — 151 rows (45 open, 106 archived), unique ids, next-id=154 above the highest, no ids deleted from base c531bc6fe66a
• npm run docs:check-links — 1414 repo path references resolve
• Prettier — clean, unpadded post-Stop Prettier padding the issues ledger table, closing #133 #1479 table style
• Placement verified explicitly: #151/#152 in Open items, #153 in Resolved / archive. My first attempt anchored on #148, which lives in the archive table, and the guard caught the misplacement as a cell-count error — worth knowing that the guard catches this.

No file other than docs/outstanding-issues.md is touched.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 46 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 631c48cd-b7d6-4b43-be74-edf9ddcfc2dc

📥 Commits

Reviewing files that changed from the base of the PR and between c531bc6 and 30ec069.

📒 Files selected for processing (1)

• docs/outstanding-issues.md

---

_{Comment @coderabbitai help to get the list of available commands.}