Clear selected and expanded call node paths on browser back button if it removes transforms

[canova]

Fixes #5689.

The root cause of this issue was that expanded call node paths from the transformed tree remained in state when navigating back via the browser. These paths were invalid in the untransformed tree, and they were causing errors when the transform was re-applied.

The fix adds a lastSeenTransformCount field to ThreadViewOptions to track the number of transforms applied to each thread. When UPDATE_URL_STATE fires via browser back button, we compare the new transform count with the old count. If we notice that a transform was removed, we reset all call node paths to ensure they're always valid for the current tree structure.

This matches the existing behavior of POP_TRANSFORMS_FROM_STACK (removing the transform from the filter navigator bar), which already resets paths.

Deploy preview: before / after

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.63%. Comparing base (48a9e86) to head (27f4f53).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5701   +/-   ##
=======================================
  Coverage   85.62%   85.63%           
=======================================
  Files         312      312           
  Lines       30880    30892   +12     
  Branches     8512     8420   -92     
=======================================
+ Hits        26441    26453   +12     
  Misses       4009     4009           
  Partials      430      430           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mstange]

Looks good, even if it feels a bit brittle.

I wonder if we have other state outside the UrlState which is affected by actions that also affect the UrlState, and which needs to be kept "in sync" with those changes. If that were the case, we might need to handle UPDATE_URL_STATE in more places to avoid similar bugs.

Ideally the answer would be "no, our actions affect either only state in the UrlState or only state outside the UrlState". So in the long run we should move these thread view options into the UrlState.

[canova]

I wonder if we have other state outside the UrlState which is affected by actions that also affect the UrlState, and which needs to be kept "in sync" with those changes. If that were the case, we might need to handle UPDATE_URL_STATE in more places to avoid similar bugs.

Ideally the answer would be "no, our actions affect either only state in the UrlState or only state outside the UrlState". So in the long run we should move these thread view options into the UrlState.

Yeah, I couldn't find more like that, but it's possible. We should still have a proper audit and move them if needed.