Preserve active tabs during navigation

[RoyLee1224]

Related

closes: #57625

What

• Improves navigation by preserving selected tab (e.g. Events, XCom) when switching between Tasks, Runs, or TIs
• Introduces hooks to to avoid prop drilling
• Extracts link generation logic in components (e.g., TaskLink, GridButton, useNavigation).
• Redirects to default tab when navigating to tasks without HITL data
• Prevents tab preservation for mapped task list views
• Removed task_instances from the allowed sub-routes list in test. It maps to "" instead of /task_instances.

Screenshots

Preserve active tabs for Runs, Tasks, and TIs

run_and_task.mp4

Before: /tasks/task/mapped/rendered_templates ❌

before.mp4

After: /tasks/task/mapped ✅

after.mp4

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[pierrejeambrun]

The problem with this approach is that it will not recall the tabs if we start switching from a TI to a DagRun back and forth. Only from TI to TI and Runs to Runs. Which is still a regression from 2.x.

In 2.x to achieve that, we would persist the active tabs in the local storage. To not have a multitude of storage entries. We could imagine 1 entry per 'type' of entities (that has specific tabs layout).

For instance, TI, Mapped TI, Task Group, Task, Run and DAG. And persist the active tab in the storage. Then everytime we redirect somewhere, read the appropriate value from the storage (depending on our current entity type), and default redirect to that if defined.

This will also have the advantage of persisting the tab accross different dags. (all groups will default to something, all Runs will default to something, etc.)

[pierrejeambrun]

This pattern seems odd. (maybe I missed something).

We allow passing isMapped, runId, taskId to the returned function. But those are actually overridden by the query params? Why do we allow to path them in the first place if those are not used?

Same for bellow hooks.

Precedence here is unclear, if we need both.

[pierrejeambrun]

Similarly to what we had before, can this come from the router definition ?

Having an hardcoded list here and in the router will make things harder to maintain. They can easily go out of sync.