Throughput: 54 open crew pulls are waiting on a builder or a reviewer. #9511

The "waiting pulls" issue the keeper files now lists the ten oldest waiting pulls, so a builder or reviewer can start at the first one. It doesn't clear the backlog itself. The 54 pulls still need a builder or reviewer. I also didn't call keep_plan, because the change was too small to need a plan.

What changed

• When the keeper's cause is stale_pile, the issue body adds an "Oldest waiting, start here" list of owner/repo#n, oldest first. Before, it only said "54 waiting" with no pointer to any pull.
• The list comes from a new oldestWaiting in src/flow/pile.ts. It uses the same crew-pull filter as readPile, and leaves out pulls with a red check or a conflict because other causes cover those.
• src/flow/keeper.ts calls it only when filing a stale_pile issue. docs/features/keeper.md has one line saying so.
• I added test/flow-pile-oldest.test.ts for the ordering, the red-pull exclusion and the limit. Without oldestWaiting it fails.

Checks run

• flow-keeper and the new test pass (16 tests).
• tsc --noEmit is clean.
• scripts/gate.ts printed nothing; I didn't check its exit code.

Not done

• The keeper still only files one issue a week for this cause. It doesn't assign reviewers or change how pulls are reviewed or merged.
• The filed list is not covered by the keeper's own test. The test exercises oldestWaiting directly, not fileOnce.

To try it Make stale_pile the keeper's cause and let it tick. The new issue's body will have the list.

Closes #9417

The "waiting pulls" issue the keeper files now lists the ten oldest waiting pulls, so a builder or reviewer can start at the first one. It doesn't clear the backlog itself. The 54 pulls still need a builder or reviewer. I also didn't call keep_plan, because the change was too small to need a plan.

What changed

• When the keeper's cause is stale_pile, the issue body adds an "Oldest waiting, start here" list of owner/repo#n, oldest first. Before, it only said "54 waiting" with no pointer to any pull.
• The list comes from a new oldestWaiting in src/flow/pile.ts. It uses the same crew-pull filter as readPile, and leaves out pulls with a red check or a conflict because other causes cover those.
• src/flow/keeper.ts calls it only when filing a stale_pile issue. docs/features/keeper.md has one line saying so.
• I added test/flow-pile-oldest.test.ts for the ordering, the red-pull exclusion and the limit. Without oldestWaiting it fails.

Checks run

• flow-keeper and the new test pass (16 tests).
• tsc --noEmit is clean.
• scripts/gate.ts printed nothing; I didn't check its exit code.

Not done

• The keeper still only files one issue a week for this cause. It doesn't assign reviewers or change how pulls are reviewed or merged.
• The filed list is not covered by the keeper's own test. The test exercises oldestWaiting directly, not fileOnce.

To try it Make stale_pile the keeper's cause and let it tick. The new issue's body will have the list.

The keeper's "waiting pulls" issue now lists the ten oldest waiting pulls, so a builder or reviewer can start at the first one. It doesn't clear the 54-pull backlog itself; those pulls still need a builder or reviewer.

The failed check was "production names the newest preview a reader may see", in test/apps-crew-side.test.ts. I think it is a one-off, though I haven't found why it failed. It touches nothing I changed, and it passed both times I ran the file on its own here. I didn't run the full suite, so I can't reproduce the failure. I made no code change. I pushed an empty commit to run the check again. If it fails again the same way, that test is flaky under full-suite load, and a person should look at it.

What changed

• When the keeper's cause is stale_pile, the issue body adds an "Oldest waiting, start here" list of owner/repo#n, oldest first.
• Pulls with a red check or a conflict are left out of the list, because other causes cover those.
• The list comes from a new oldestWaiting in src/flow/pile.ts, called from src/flow/keeper.ts. docs/features/keeper.md has one line saying so.
• test/flow-pile-oldest.test.ts covers the ordering, the red-pull exclusion and the limit.

Left out

• The keeper still files one issue a week for this cause. It doesn't assign reviewers or change how pulls are merged.
• The filing path (fileOnce) has no test of its own; the test exercises oldestWaiting directly.

To try it Make stale_pile the keeper's cause and let it tick. The new issue's body will have the list.

All three points are fixed and pushed. The new tests, flow-keeper.test.ts and tsc pass, and scripts/gate.ts printed nothing. scripts/fast.ts said the diff was too broad to name tests, so I ran the two files that cover it. I did not run the full suite.

What changed

• Privacy: oldestWaiting now defaults publicOnly to true. fileOnce in src/flow/keeper.ts passes repo.visibility !== "private", so private repo names and pull numbers go into the issue body only when the forge's own repo is private too. I exported fileOnce so the tests can call it.
• Tests: three added to test/flow-pile-oldest.test.ts.

- A conflicted pull is left out of the list. - A private repo is left out by default and named only with publicOnly=false. - The stale_pile issue body that fileOnce files contains the oldest-waiting list. It omits the private repo while the target repo is public, and names it once the target is private.

• Import order: ./pile.ts now follows the ../core/ and ../kernel/ imports, after keeper_rate.ts.

Direction: I'm not claiming a pipeline item. This is a pointer in the weekly keeper issue and doesn't move #6534, #6611, #5276 or #3316. It only lets whoever opens that issue start at the oldest waiting pull instead of searching the pile. If you'd rather hold it behind those, leave it unmerged; nothing else depends on it.