Renovate has not run against this repo since 2026-08-10 — a security PR sat unmergeable for 10 days

## What happens

Renovate has not run against this repo since **2026-08-10**. It is running normally against
`celo-org/mondeto-admin`, so this is repo-specific, not an org-wide outage.

Evidence, gathered 2026-08-27:

| | mondeto | mondeto-admin |
|---|---|---|
| Dependency Dashboard last updated | **2026-08-10** | 2026-08-27 (today) |
| Most recent commit on any `renovate/*` branch | **2026-08-10** | today |
| Reaction to a PR merging | none | opened a new PR within minutes of #66 merging |
| Reaction to a ticked `rebase-check` box | **none after ~1 hour** | n/a |

I ticked the rebase checkbox on #206 and Renovate did not act on it. The box on #202 was **already
ticked before I touched it** and had not been acted on either.

## Impact

Three PRs sat unrebased and unmergeable for 10-17 days, including **#202, a `next` security update**.
`apps/web/package.json` still resolves `next` to 15.5.20 on `main` while the patched 15.5.21 sat in a
conflicting PR nobody could merge. mondeto-admin took the equivalent fix on 2026-08-10.

More generally: the player-facing app is the repo that is **not** receiving dependency updates, while
the internal admin tool is. That is exactly the wrong way round.

## Root cause — NOT diagnosed, needs the Mend dashboard

I could not determine the cause from the repo side, and I do not want to guess at it in a ticket.
What I ruled out:

- **Not config drift.** `renovate.json` is byte-identical between the two repos (same
`config:recommended`, same `rebaseWhen: behind-base-branch`, same `prConcurrentLimit: 3`, same
package rules).
- **Not the branch protection ruleset** — mondeto-admin has the same protections and is fine.

The most likely candidate, worth checking first: `prConcurrentLimit: 3` with exactly three open
Renovate PRs (#89, #202, #206). That caps *new* PRs — but it should not stop rebases of existing ones
or dashboard updates, and the dashboard is 17 days stale, so it does not explain the whole picture on
its own.

Needs someone with access to the Mend/Renovate dashboard to read the job log for this repo.

## Suggested fix

1. Check the Renovate app installation covers `celo-org/mondeto` and read the last job log.
2. If it is the concurrency cap, land or close the three open PRs and confirm Renovate resumes.
3. Once running, confirm it rebases a deliberately stale branch — verify from the outside, not from
the settings page.

**Interim, already done:** #202 and #206 were rebased by hand (lockfile regenerated on current `main`
with `corepack pnpm` so `lockfileVersion` stays 6.0), so neither is blocked on this issue any more.
#89 is separate — it is red on `web · type-check + tests` for its own reasons.

## Non-goals

Not changing `renovate.json`, since it is identical to a repo where Renovate works. Not raising
`prConcurrentLimit` until the cause is actually known — that would be treating a symptom.

## Acceptance criteria

- [ ] Cause identified from the Renovate job log and written here
- [ ] Renovate observably runs against this repo again — Dependency Dashboard timestamp moves
- [ ] A deliberately stale Renovate branch gets rebased automatically, verified by observation
- [ ] If the cause can recur silently, say how we would notice next time

## How we'd know it's fixed

The Dependency Dashboard updates on its normal schedule, and a security advisory produces a mergeable
PR here as quickly as it does in mondeto-admin. The check that matters is a **dated** dashboard, not a
green settings page.