ClawSweeper can leave stale review-started placeholders and repeatedly re-trigger the same issue

Summary

ClawSweeper appears able to get stuck on an issue by posting a review started placeholder / lease comment, failing or timing out before replacing it with the actual review result, and then repeatedly starting new shard attempts for the same issue.

The clearest observed case is #3076.

Observed behavior

On #3076, GitHub email notifications show repeated ClawSweeper attempts from July 13 through July 22, 2026. The repeated notification pattern is:

• ClawSweeper status: review started.
• one item in the current shard
• a shard identifier such as Shard 19/30, Shard 0/1, Shard 24/27, etc.
• a lease marker like clawsweeper-review-status:started item=3076 ... lease_expires_at=...
• no corresponding completed review edit for many of those attempts

In the Gmail notification thread for #3076 I saw 32 GitHub notification messages. There was one useful review result early on, but many subsequent notifications were only fresh review started placeholders. The latest currently visible placeholder I checked was:

https://github.com/openclaw/clawhub/issues/3076#issuecomment-5042221159

That comment has:

ClawSweeper status: review started.
...
Shard 24/27.
...
lease_expires_at=2026-07-22T06:01:48.230Z

The lease had already expired by the time I reviewed it, but the issue still had a visible placeholder rather than a clear failed/stale/inactive result.

Why this matters

This creates two related problems:

1. Issue noise: maintainers and authors get repeated GitHub notifications that do not contain a completed review or actionable result.
2. State ambiguity: a visible review started comment can remain after the lease has expired, so it is unclear whether ClawSweeper is actively working, failed, backed off, or will retry again.

For #3076 specifically, this also made the issue look more chaotic than necessary even though the underlying issue is still valid and waiting for a maintainer product/security decision.

Expected behavior

ClawSweeper should avoid repeatedly notifying issue participants with fresh placeholder-only attempts when the same item is already blocked, stale, or awaiting maintainer direction.

Possible fixes:

• Reuse one durable status comment per issue and edit it to failed, stale, inactive, or awaiting maintainer decision when a lease expires without a completed review.
• Before starting a fresh shard review, check whether an unexpired or recently expired lease/status marker already exists for the same item and suppress duplicate starts.
• Add a backoff or retry budget for issue reviews that repeatedly fail before completion.
• If a review cannot complete, emit a short terminal status with the failure class and next retry time instead of leaving review started as the latest visible state.
• If ClawSweeper marks an issue as needing maintainer/product/security review and no-new-fix-pr, avoid scheduling daily fresh reviews unless an issue body/comment/label/code revision change makes a new review useful.

Reproduction evidence from #3076

• Issue: #3076
• Current hanged placeholder checked: https://github.com/openclaw/clawhub/issues/3076#issuecomment-5042221159
• The earlier useful review comment exists and says the issue should stay open for maintainer follow-up.
• The repeated later emails were mostly review started placeholders with different shard numbers and lease owners, not completed review results.

Open question

Is the intended model that ClawSweeper keeps one durable marker-backed review comment per item? If so, the stale lease / repeated placeholder path seems to violate that model and should probably be guarded at the scheduler or lease-comment update layer.