A conflicted pull never sits: brought up to date within the hour, or closed with its issue back on the map #2050

Every tick now brings a conflicted crew pull up to date, or closes it and puts its issue back on the map. I ran the new test and the autonomy and flow suites (37 tests, all passing) and the type check. I did not run the forge's full check.

What changed

• Sweep each tick: sweepConflicts in src/crew/autonomy.ts runs in autonomyTick before the builder picks. It checks every open agent-authored pull against its base. The old path only noticed conflicts on green pulls inside landIfGreen, so the conflicted pulls that never turned green were never reached.
• Queued run: A conflicted pull gets a bring-up-to-date run, with one in flight per pull. Pulls under a person's hold are skipped.
• Release: Once nothing is in flight, the pull is closed with a note naming the conflicting files and the reason. That happens after two finished attempts, or when the first attempt is 24 h old. Any issue it closes loses its assignee and gets a "Ready again" comment naming the files.
• No strike: The new releaseConflicted writes comments that don't start with the parked-by-the-crew prefix, so nothing counts as a strike on the issue or the builder. bringUpToDate's own limit uses it now too, in place of parkPull.
• /flow: The new src/flow/conflicted.ts lists conflicted pulls oldest first with their age, read from the run table with no git call. It shows in the terminal Flow dialog and as #conflicted on the web page.
• Test: test/conflict_sweep.test.ts makes a pull conflicted by a landing and checks that one run is queued in the first tick and a second tick adds none. After two failed runs the pull is closed, the issue is open and unassigned with the files named, and the strike count is 0.

What I left out

• Age and attempt counts: Both come from the pull's conflict runs, with no per-episode reset. A pull that is conflicted twice at different times on separate landings counts both episodes' attempts, so it can close sooner than "two failed attempts" in the same episode.
• Pulls with no agent: A conflicted pull whose author is not an agent, or that has no agent to run, is not touched. With no run, there is no starting time to measure 24 h from.
• MCP: The flow tool does not report conflicted pulls yet.

Try it: bun test test/conflict_sweep.test.ts, or open /flow as an admin.

Closes #2039

A conflicted crew pull is now brought up to date every tick, or closed with its issue back on the map. The first check failed only because the new test file wasn't listed in scripts/gate.ts. I added test/conflict_sweep.test.ts to GATE and pushed. bun scripts/gate.ts now passes, but I haven't seen the forge's re-run of the check.

What changed

• Tick sweep: sweepConflicts in src/crew/autonomy.ts runs in autonomyTick before builder picks. It checks every open agent-authored pull against its base. Before this, a conflict was only noticed on green pulls inside landIfGreen, so conflicted pulls that never turned green were never reached.
• Bring up to date: A conflicted pull gets a bring-up-to-date run, with one in flight per pull. Pulls a person holds are skipped.
• Close and free the issue: After two finished attempts, or 24 h since the first, the pull is closed with a note naming the conflicting files. Any issue it closes loses its assignee and gets a "Ready again" comment.
• No strike: The comments don't use the parked-by-the-crew prefix, so nothing counts against the issue or the builder. bringUpToDate's own limit now closes this way too, instead of calling parkPull.
• /flow: The terminal Flow dialog and the web page list conflicted pulls oldest first with their age. The list is read from the run table, with no git call (src/flow/conflicted.ts).
• Test: test/conflict_sweep.test.ts covers a landing that makes a pull conflicted. It checks that one run is queued per tick and that two failed runs close the pull and free the issue with no strike.

Left out

• Attempt and age counts don't reset per conflict episode, so a pull conflicted twice at different times counts both episodes' attempts and can close sooner than "two failed attempts" in one episode.
• A conflicted pull with no agent to run is left alone, since there's no first run to measure 24 h from.
• The MCP flow tool doesn't report conflicted pulls yet.

Try it: bun test test/conflict_sweep.test.ts, or open /flow as an admin.

Both correctness problems are fixed and pushed: a pull that was brought up to date before is no longer closed for it, and the sweep no longer runs git on every pull every tick. The type check and the autonomy, flow and MCP suites pass (60 tests). I haven't seen the forge's check on this push.

What changed

• Current conflict only: Attempts and the 24 h clock now count from the start of the current conflict. That start is the later of a person's last word and the last time the sweep saw the pull merge cleanly. bringUpToDate takes the same start, so its own two-try limit no longer counts earlier conflicts either. After a restart nothing is remembered, so the start falls back to the finish of the last successful run.
• Which runs count: Runs in the current conflict that finished, whether ok or failed, count as failed attempts. I count ok as well because an agent run that exits "ok" without fixing the conflict is still a failed attempt, and the sweep only counts a run while the pull is still conflicted. You asked for failed only. If you want that, say so, but a run that ends well without pushing would then never close the pull.
• Test: A new test in test/conflict_sweep.test.ts has the pull conflicted and brought up to date three times, each time with a successful run. The pull stays open each time. The old code closed it on the third conflict.
• Git cost per tick: sweepConflicts now runs mergeable only when a pull's head or its base tip has changed since the last read. An unchanged conflicted pull reuses the cached files and still moves toward its attempt or age limit. I didn't add a cap per tick, since an unchanged pull now costs no git call.
• MCP: The flow tool now returns conflicted with a sentence and the pulls, oldest first.
• README: The Flow paragraph now says conflicted pulls are swept every tick, closed after 2 failed tries or 24 h, and listed on /flow.

All the review points are fixed and pushed. The type check and the conflict-sweep, autonomy and flow-pipeline suites pass (31 tests); I haven't seen the forge's check on this push.

What changed

• A push starts a new episode. If a pull's head differs from the head the sweep last read, the builder pushed, so attempts and the 24 h clock restart from that moment. A successful run followed by a new conflict no longer counts against the pull. The new test ends three successful runs with the pull still open. It fails if I turn the head check off.
• Caches are pruned. Each sweep drops the checked and cleanAt entries of any pull that is no longer open, and a release drops its own entries at once.
• MCP reads conflictedPulls once.
• New tests, all in test/conflict_sweep.test.ts:

- 24 h close: backdate the first conflict run and the pull, and assert the pull closes with the "within 24 hours" reason and its issue is freed. - Web: /flow for an admin shows #conflicted with the pull while it is conflicted, and doesn't show it once none is. - MCP: the flow tool returns conflicted with the same pull and sentence, and an empty list when none is conflicted.

Where I differ from the review

• ok runs still count as attempts within an episode. An ok run that left the head unchanged is a failed attempt, so I count it. A run that pushed is covered by the head check above.
• After a restart the sweep remembers nothing. The episode then starts at the last successful conflict run, so the first conflict seen after a restart gets a fresh count.