fix: prevent stale review results from delaying publication

[zhangguiping-xydt]

What Problem This Solves

Fixes an issue where users waiting for a ClawSweeper review could see an older verdict published before a newer completed verdict when multiple exact-review artifacts for the same item were queued.

This was observed on openclaw/openclaw#111774: a newer no-findings, proof-sufficient review artifact already existed, but an older needs proof artifact consumed the publisher first and the public review comment remained stale.

Why This Change Was Made

The exact-review queue now orders publications for one item by the existing review revision and producer run tuple during enqueue. It transactionally supersedes older pending or parked publications, rejects delayed stale deliveries, and reuses the queue's existing supersede deletion and metrics path.

Dispatching and leased publications are deliberately preserved so enqueue does not invalidate active work. The change stays inside ExactReviewQueue, which already owns publication admission, durable state, and supersede accounting.

User Impact

The newest completed ClawSweeper review gets publisher capacity sooner. Operators should see less duplicate publication work, lower stale backlog, and fewer cases where a public review comment lags behind an already completed newer result.

Evidence

• Production before-state:
  • PR comment remained at review started / stale verdict: fix(providers): usage returns empty data when a provider response is malformed openclaw#111774 (comment)
  • Newer review result existed before publication completed: https://github.com/openclaw/clawsweeper/actions/runs/29733996086
  • Older artifact publisher ran first: https://github.com/openclaw/clawsweeper/actions/runs/29738680960
• Added regression coverage proving:
  • newer publications supersede older pending and parked publications for the same item;
  • a delayed older run cannot displace a newer queued result, even when its claim generation is numerically higher;
  • unrelated PRs remain independent;
  • dispatching and leased publications are not deleted;
  • completed/superseded metrics account for removed queue work.
• node --test test/dashboard-worker.test.ts: 158 passed, 0 failed.
• pnpm run build:dashboard, dashboard/test lint, formatting, and focused regression tests passed on Node 24.16.0.
• Full pnpm run check reached 1,413 unit passes with 0 failures (1 platform skip). The later repair suite is not runnable cleanly on this host because its Git is 2.27 (git init -b unsupported), Linux namespace containment is unavailable, and outbound validation fetches time out; CI should provide the canonical repair-suite result.

[brokemac79]

@zhangguiping-xydt - there is currently an issue with clawsweeper publication backlog that is currently being worked on. this is the underlying cause of the problem you are seeing here. therefore, unless you believe otherwise, pls close this PR.

[zhangguiping-xydt]

Thanks for the context. Could you point me to the issue, PR, or branch for the publication-backlog work in progress?

This PR specifically coalesces older pending and parked publication artifacts at enqueue time; it does not fence a publisher that is already active. Once I can compare the two scopes, I’m happy to close this PR if it is duplicate work, or move its regression scenarios and evidence to the canonical fix.

[brokemac79]

Thanks for the context. Could you point me to the issue, PR, or branch for the publication-backlog work in progress?

This PR specifically coalesces older pending and parked publication artifacts at enqueue time; it does not fence a publisher that is already active. Once I can compare the two scopes, I’m happy to close this PR if it is duplicate work, or move its regression scenarios and evidence to the canonical fix.

there's multiple :-) it's a bit like having to unpeel an onion.. you fix one problem and then there's another layer and another :-)

i hope to have it back in a fully working state soon. but you can check PRs by my user , though i'd wait until i confirm it's fully fixed. if i don't get a chance, you would be able to see if things are working well again, this chart on https://clawsweeper.openclaw.ai/ goes back towards zero