Bug 1681310 added a method of texture upload where all uploads for the frame are packed into one staging texture, and then copied to the various destination textures using draw calls.

The contents of this texture are only needed for the duration of one frame. So we know that it'll be unused in the next frame. This makes its lifetime management very simple, and makes it an ideal texture to use client storage on, to reduce CPU time spent on copies.

Strictly speaking, the contents are needed for as long as it takes GPU to copy them. If the GPU is 2-3 frames ahead of the CPU, then from CPU perspective it needs to keep the contents around for 3+ frames.

Ah, yes, I meant "only needed for the GPU work of one frame".
So, on frame n, we cannot use the same staging texture as frame n-1. However, we can re-use staging textures from frame n-2 and ensure that the GPU is done with them using a fence, like we do in Gecko's existing client storage texture code.

With WebRender we already use a fence at the end of frame n-1 to wait for the GPU to finish its work on frame n-2, so we know that the GPU is done with frame n-2 by the time we start the CPU work for frame n. So the new fences for the client storage textures should not introduce any new blocking.