Ladon self-locks gated PRs after a requested change is fixed

[bokelley]

Summary

When Ladon requests changes for a real finding, then a later run verifies that finding is fixed but must escalate because the PR touches a gated path, the original CHANGES_REQUESTED review remains active. The escalation logic then reads that same review state and repeatedly reports that human approval is required, leaving the PR self-locked by Ladon's superseded review.

Reproduction

Observed on adcontextprotocol/adcp#7363:

1. On head 8841e829, Ladon correctly requested changes because a breaking schema narrowing used a minor changeset.
2. The author changed the changeset to major in 90aab3de.
3. On heads 90aab3de and 6bfd712f, Ladon reported a clean delta with no Critical/High/Medium findings, but submitted COMMENTED escalation reviews because static/schemas/source/** requires human/CODEOWNERS approval.
4. The original review remains CHANGES_REQUESTED; the fixed inline thread is outdated and now resolved, but GitHub's PR reviewDecision is still CHANGES_REQUESTED and merge remains blocked.
5. The current-head Ladon review uses that state as an escalation reason and says a human approval will flip review_decision to APPROVED. The outstanding Ladon change request may instead need explicit dismissal, creating a confusing circular gate.

Relevant reviews:

• Original change request
• Clean current-head escalation

Expected behavior

After Ladon verifies that all of its blocking findings are fixed and transitions to a human-only escalation, its superseded CHANGES_REQUESTED state should no longer block the PR. Possible approaches:

• dismiss/clear Ladon's prior change-request review before submitting the escalation; or
• model the hard gate independently of the aggregate reviewDecision, and clearly instruct maintainers to dismiss the superseded bot review when GitHub cannot clear it automatically.

The system should preserve the human/CODEOWNERS hard gate without requiring maintainers to diagnose stale bot-review state.