Fix vm link on services subtable

[GilbertCherrie]

Fixes: #9252

Fixes an issue where the VM page summary page was being cached on Firefox. This meant that when you were trying to visit a VM summary page by a link, such as through the Services VM table, it visited URLs like http:/localhost:3000/vm_infra/show/1, which the UI was redirecting to http:/localhost:3000/vm_infra/explorer. Firefox was caching this page and because the URL wasn't changing it assumed you were viewing the same VM regardless of whether the ID was changed or not. This PR makes the explorer visit the URL http:/localhost:3000/vm_infra/explorer/v-1, which tells Firefox that it is visiting a new VM each time and rendering the correct VM summary page for each VM.

[GilbertCherrie]

As a follow-up to this PR, I was going to fix this issue: #6696 and allow the URL to accept raw IDs instead of tree IDs

[miq-bot]

Checked commit GilbertCherrie@1f1c1be with ruby 3.3.10, rubocop 1.88.2, haml-lint 0.76.0, and yamllint 1.37.1
1 file checked, 0 offenses detected
Everything looks fine. 🍰

[Fryguy]

As discussed, let's try to dig further into this before considering this PR as this PR feels like workaround a deeper problem.

When running through Firefox the correct explorer is being rendered and then for some reason we see a second redirect which blows it away. On Chrome we don't see that second redirect, and the original render holds. However, this is all happening on the backend, so there's something about how the backend reacts to each browser, or Firefox is issuing something after the first render. Either way, there's some wrong on the backend, which we shoulld try to solve first.

Incidentally, if FIrefox is "double-rendering", I wonder if that's contributing to the signifcant time it takes to run the cypress tests. cc @jrafanie @asirvadAbrahamVarghese

[Fryguy]

Discussed with @GilbertCherrie and used some AI inference, and it came to a similar conclusion as Gilbert. The AI said that effectively we have a non-deterministic state based on a possible session race, and it's possible that timing between the 2 browsers affects the output. The best fix is an explicit redirect with the id instead of relying on it being in the session, storing the session, and hoping the redirect pulls the correct value back out of the session.

However, we're going to be even more explicit and rely on #10244 and then use ids instead of tree nodes. This also sets up up better for de-explorization where we would redirect to an id specific resource anyway.