qodo_open Double-Counts and Never Clears the Open-Source Qodo App's Threaded Findings

[ptr727]

pr_review.py's qodo_open reads Qodo's findings from its Code Review by Qodo comment and treats a finding as closed only when it carries Qodo's Resolved or Dismissed badge. That fit the paid app. The open-source app, qodo-free-for-open-source-projects and the only Qodo identity left since the paid app was uninstalled, behaves differently:

• It opens a review thread for each finding, so the finding is already counted in unresolved=. qodo_open then counts it a second time and prints "no thread to resolve" for it.
• Resolving the thread adds no badge to the findings comment, so qodo_open never drops back to zero. Merge Gate item 3 then sends the driving agent to re-answer findings that are already resolved, every round.

Measured with the open-source login tracked: on ptr727/PlexCleaner#999 and #1000, every Qodo thread is resolved, yet status reads qodo_open=3 and qodo_open=2.

What was tried, and why it was backed out

Three rounds on the branch that switched the login matched each comment finding to its thread by its heading. Each local review pass found new defects. The last one is decisive:

• The number is not shared. The findings comment and the threads number the same finding independently, even within one round. Across 559 historical numbered findings (PlexCleaner from both logins, plus 200 ProjectTemplate PRs from the paid login), 359 have a thread with the same title under a different number. ProjectTemplate Settle the Workflow CI Contract Skill Against Its Sources #1252 shows it within a single round.
• Prefix matching hides findings. A startswith match let a thread whose title extends a finding's title clear that finding, and a code-led title reduced to its number alone matched any thread with that number. Both are the silent direction: the finding drops out of qodo_open= and unresolved= alike.
• Code spans and trailing labels need symmetric handling. Real titles never carry <code> or backticks (0 of 559), since Qodo renders code in a title as <b><i>...</i></b>, but a matcher that strips them on one side only breaks on the constructed case.
• The regexes must stay linear. A lazy <[^>]*> and a trailing-label pattern anchored with $ both took quadratic time on a long line. The file's existing BARE_TAG does that job in linear time.

The direction the last round pointed to

Match on the title alone, with the number dropped. Normalize both sides the same way: the first numbered line, every code span removed, markup stripped with BARE_TAG, escapes removed, case folded. Never match an empty title. Let each thread clear at most one finding with that title, so a re-raised duplicate stays open. That keeps any error in the loud direction. Alternatively, decide that on the open-source app qodo_open should count only the findings that have no Qodo thread on the pull request at all, which may be simpler. Either way, every rule above deserves a test, and the PlexCleaner and ProjectTemplate history above is the corpus to check a design against.

Until this lands, a PlexCleaner pull request shows resolved Qodo findings as qodo_open. That is a loud error, never a hidden finding, so answer them by checking each one's thread state.

Relates #1404, #1465.