UI: Preserve Grid limit and filters when redirecting after manual Dag trigger

[yuseok89]

On a Dag detail page, when a filter or the Grid run limit is applied and a Dag is then triggered manually, the post-trigger redirect resets the filter and limit back to defaults.
Preserve them across the redirect so the applied filters survive.

Before

Screen.Recording.2026-05-11.at.9.57.01.PM.mov

After

Screen.Recording.2026-05-11.at.10.06.50.PM.mov

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  • Opus 4.7

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[parkhojeong]

Thanks for the focused fix. I had a couple of thoughts while reviewing

[parkhojeong]

1. Query Param Scope

I think preserving the entire search string here is a bit too broad. Some of these params are not just passive UI state. for example run_after_lte defines the Grid's run window in DetailsLayout.

If a user is currently looking at an older run/window and triggers a new Dag run, this redirect will carry the old run_after_lte forward. The details pane will navigate to the new run, but the Grid can still be constrained to the previous time window and exclude the run we just created.

Could we preserve only the params that are intended to survive this transition, such as limit and explicit user filters, and either drop or recompute the Grid window/date params for the newly triggered run?

2. Router Location Source

Could we use useLocation() for the current search string instead of reading globalThis.location.search directly?

This hook already operates inside React Router via useNavigate() and useParams(), so keeping the location read in the same abstraction makes the behavior easier to reason about and test. It also avoids coupling this hook to the browser global, which is awkward in MemoryRouter tests and any non-browser render path.