We did some premature optimization here and said the last step never needs a step cache result, since that would mean the execution has a cache result, too.
Since we need the cache result for the UI as well, this meant that the last step would never show up as "cached" for a fully cached workspace and have no diff as well.
This fixes it by including ALL steps.
This reveals one quirk of our current caching mechanism (it was even worse before so no reason not to make this change, but still want to point it out):
When we evict the cache result for the execution, but still have all for the steps in the cache, we invoke src-cli in the executor, just to run some very simple conversion code that turns the step result into the final result (no actual execution required for that). This doesn't break anything, it's just not the most efficient thing in the world.
Before this change, we would also need to re-execute the last step always, this is not happening anymore now.
I want to file a follow up to drop cache results from SSBC entirely and port the logic to convert a step cache result into changeset specs into the backend. Then no executor run would be required for this scenario at all and we would reduce data duplication in the database.
Test plan
Validated the last step of a cached execution now also properly appears as cached, not skipped.
