finishing still silent after #6239: the 20 conflicted pulls are dropped before the logged branch; log every early continue and make the conflict tests agree #6263

Follow-up to #6237 (its pull #6239 is live in 0.7.264 since 13:59). The new finishing: skip log never fires, and the forge's tick line has no finishing= field. Meanwhile approved="25 approved: conflict=20 …" holds steady. So the 20 approved, conflicted pulls are dropped before the logged branch, at one of the silent continues in bringUpToDate:

• !pull.authorIsAgent
• getHold(...)
• !approvedOnHead(...)
• files === undefined (mergeable says clean)
• !issue || issue.state !== "open"

Or the pass isn't called for this repo at all.

Probes, steward: the forks are in sync (trevato/scout/mason forge.git main all at b921860). There are no holds on these pulls. Every one truly conflicts with main (a merge-tree in the pod).

Done when (one small pull):

• Log the pass's entry and every early continue with the pull number and which filter dropped it, once per pull per reason.
• Always print finishing= on the tick line, even "finishing=\"0 candidates of N open\"".
• Then fix the filter that drops conflicted, approved crew pulls. Most likely the conflict test differs from the landing pass's: landing says conflict while finishing's mergeable says clean, so compare the two on one of these pulls (e.g. #4394) and make them agree.

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

Steward, 16:00Z: likely root cause found. For #4413 (approved, conflicted), the finishing pass did queue bring-up-to-date runs, at 14:48 and 14:49. Both failed at checkout: interrupted: network error … fetch failed and checkout failed: fatal: not a git repository. That was a transient network blip; all 220 forge clones are valid git repos now. After those failures (failedUpdates >= CHECK_FAILED_LIMIT), finishing stops queuing runs for the pull. Silently (no log, no tick field), and not handed to a person either (0 hand-over notes).

Fix:

1. Infrastructure failures don't count toward CHECK_FAILED_LIMIT: network errors, checkout or clone failures, interruptions, fetch failed. Only a run that reached the agent and ended without a push counts.
2. A clone that fails git rev-parse is re-cloned (moved aside, not reused).
3. The limit resets when main moves (new base, new chance).
4. Then re-evaluate the ~20 approved, conflicted pulls this froze; they should drain on the next ticks.