fix(ui): avoid reloading PodView quickstarts on rerender

[Vedant-Mhatre]

Fixes #24831

Summary

PodView currently recreates quickstart button loading inline during render, which causes quickstart action loading to run again on unrelated rerenders. In practice that means interactions like group expansion or panel updates can retrigger quickstart permission requests.

This change moves quickstart action loading behind a memoized component and uses a stable serializable DataLoader input so quickstart actions only reload when the relevant resource/application/tree inputs change.

Verification

• Added regression coverage for:
  • unrelated parent rerenders do not reload quickstart actions
  • resource changes still reload quickstart actions
  • appChanged subject identity changes still reload quickstart actions
• Ran:
  • corepack yarn test --runTestsByPath src/app/applications/components/utils.quickstart.test.tsx src/app/applications/components/utils.test.tsx --runInBand
  • ./node_modules/.bin/tsc --noEmit --project ./src/app
  • ./node_modules/.bin/eslint src/app/applications/components/utils.tsx src/app/applications/components/utils.quickstart.test.tsx --no-warn-ignored

[bunnyshell]

🔴 Preview Environment stopped on Bunnyshell

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

• 🔵 /bns:start to start the environment
• 🚀 /bns:deploy to redeploy the environment
• ❌ /bns:delete to remove the environment

[choejwoo]

Also, if you have a screenshot or short video showing the before/after behavior in the repro environment, that would make this easier to review.

[choejwoo]

Generally, this looks good to me.
I wonder if quick start actions could still reload on unrelated watch-driven resource tree updates, since input still includes the full application and tree. Would it make sense to narrow input to only the fields needed to resolve quick start actions?

[Vedant-Mhatre]

Good point. I narrowed the DataLoader input in the latest update so it no longer depends on the full application / tree objects.

It now keys off only the fields that affect quickstart resolution for this path:

• the selected resource identity
• whether the resource is managed
• the derived child-resource set used by delete handling
• whether a logs target exists
• the application identity/project
• stable identities for the underlying apis managers and appChanged

I also added regression coverage for the case you called out: refreshed application / tree objects that do not change the effective quickstart behavior no longer reload quickstart actions.

There was one similar issue with the recreated apis wrapper as well, and I narrowed that too. The latest push includes both fixes; checks are rerunning on it now.