Incremental / continuous staging ("merge queue" / "merge train")

• A staging 1 is created with PR A and PR B.
• PR C is r+ later while the staging is running
  • A secondary staging 2is created with PR A, PR B and PR C
    • if staging 1 is green, the PR A and PR B are merged, PR C is merged right after if it's green
    • if staging 1 is red, everything is discarded

Dependencies

• Support for co / multi-stagings per branch, like #497 (or the idea of pre-staging splits before the CI has even failed, which I apparently didn't create a task for).

Considerations:

• Thresholds / bounds? In theory this can mean 16 concurrent stagings per branch if there's a continuous stream of ready PRs with enough delay for their pickup.
• If no thresholds, should batches still be batched or e.g. if 3 PRs are ready to we create a stack of 3 stagings? In that case we can remove splits entirely.
• Synchronisation if later stagings are faster than earlier (on success we can merge the later stagings directly and cancel the previous two, on failure we need to wait to see which PR caused the failure).

Issues

• Much lower resilience to non-deterministic failure e.g. if (1) passes and (2) fails we immediately consider (2) is broken, there's no rescue.

• Possibility of odd behaviour in case of nondet failure e.g. if staging 4 succeeds but 3 fails it is a form of nondet, but we may already have failed (3)... then again if 4 succeeds before 3 fails we should have cancelled (1) - (3), just needs to be tested...

  Might need some sort of grace period on failure to mitigate impact of nondet failures.

Start by reviewing the existing staging behavior and the multi-staging support referenced in issue #497. The issue does not name files or tests; completion would require resolving batching, thresholds, synchronization, and nondeterministic-failure handling, then defining tests for those cases.