There's no need to do this and not doing so speeds up IMM tremendously when the sparse profile had to be adjusted.
Discussed this in person. My concerns were that this would allow large action lists to propagate up and cause excess remotefilelog actions. Phil's response was that A) this only applies to rebases for now, and any action in the rebase is going to require downloading anyway (when it the sparse profile gets temporarily expanded below), and B) any action on a in memory context should probably not be filtered by sparseness anyway. I think the invariant in B is reasonable, and if we see it causing problems like A we can reevaluate how to fix that problem to meet invariant B.
Looks fine. It might be nice to come up with some better terminology. I think of "working copy" as always referring to the physical on disk one, so maybe we need some other term for a mutable context (of which working copy would be one type).