[Impeller] Check the correct stencil coverage when deciding whether to elide a restore

[bdero]

Just noticed this while carefully reviewing the stencil coverage stack again today. This is much more rare/a subset of the original issue that was fixed by #38964, but could still result in lots of draw calls getting culled. Slightly modified the playground to detect this case too.

Before

After

[bdero]

Correction: This wouldn't result in excess culling of draw calls -- it actually results in some stuff getting inverse clipped by anything above the restored value because the stencil check uses strict equality (as can be seen in the playground screenshot).

Mercury really needs to be in retrograde for an app to be affected by this, so it's not as much of an emergency, but could cause big weird problems for the poor soul that runs into it:

1. We can only hit this if the stencil stack prior to restore happened to have empty coverage, and
2. just like the original bug, multiple clips need to be getting restored by one restore entity. -- this isn't true. Actually any restore from empty coverage may break subsequent draws.

[bdero]

@zanderso Should we do a cherry pick for this one too? This isn't present on gallery/wondrous, but I won't say it doesn't worry me.

[zanderso]

@bdero Yeah, we can. I only hadn't because I interpreted #39023 (comment) as saying that it wasn't worth a CP. I'll draw up the issue.

[bdero]

@zanderso Makes sense, thanks. When this came across my mind today I realized this doesn't seem terribly rare. Any restore from empty stencil coverage will break subsequent draws (including clips). The stencil buffer will basically be in a bad state that will only recover the next time a restore happens from non-empty stencil coverage.

The fact that it'll only happen when restoring from an empty clip is what's saving us. I bet stuff that regularly animates clips (e.g. rive animations) will trigger this.