Stacked PR landing workflow is awkward whether landing from bottom or top

What is the recommended way to land a stacked GitHub PR series with Sapling?

I created the stacked PRs with sl pr submit. For a stack like:

B  top PR
A  bottom PR
main

I tested both obvious landing workflows on GitHub, and neither was a good experience.

If I land the bottom PR first:

1. A lands.
2. The remaining PR for B can still carry the old local copy of A.
3. GitHub may show B as conflicting.
4. Recovery requires a manual loop:

sl pull
sl rebase -s <first-still-open-commit> -d remote/main
sl pr submit

Then repeat for the next PR.

If I land the top PR first:

1. The final combined diff lands on main.
2. The lower PR remains open.
3. The lower PR becomes conflicting/dangling and must be closed manually.
4. The stack is effectively collapsed into the top PR rather than landed as a stack.

So bottom-first becomes a land/rebase/submit loop, while top-first leaves lower PRs behind.

Is there a Sapling-native workflow for landing a stacked GitHub PR series cleanly? Ideally Sapling would either provide a command for this, document the expected sequence, or guide recovery when a landed lower GitHub PR leaves the remaining stack carrying an already-landed commit.