storage: guard against `build_fallible` footgun

[petrosagg]

Because the capabilities that we retained were stored in a btree map which was part of the future state, when we encountered an error and returned from the future those were dropped and created bogus frontiers that propagated down the dataflow. This can cause incorrect data to be persisted. Until build_fallible is fixed we must implement this ugly workaround.

Fixes #23287

Motivation

Tips for reviewer

Checklist

• [ ] This PR has adequate test coverage / QA involvement has been duly considered.
• [ ] This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• [ ] If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• [ ] If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• [ ] This PR includes the following user-facing behavior changes: