Extend user settings with additional configuration

[dsuhinin]

Right now every task instance opens on the Logs tab, and the app always lands on the Home dashboard. If you prefer something else, you're clicking your way there every single time. This adds two small, opt-in preferences on the Settings page so each user can pick better defaults — and if you don't touch them, nothing changes.

Both preferences are per-user and stored in this browser's localStorage (via useUserSettings); there is no server-side profile and no deployment-level config involved.

Default landing page (default_landing_page, defaults to dashboard) sets what the root URL opens. Switch it to dags and / takes you straight to the Dag list. The dashboard is still there — it now lives at /home, so you don't lose anything. A tiny LandingPage component at the root index route just reads the stored value and either renders the dashboard or redirects to /dags — all client-side, no server-side routing.

Default task instance tab (default_task_instance_tab, defaults to logs) sets which tab a task instance opens on (say, details). The task-instance index route renders a DefaultTab component that reads the stored value and redirects there, keeping the query string and hash intact. Logs now also has its own explicit logs route, and any unknown or unset value falls back to Logs — so existing behavior and deep links stay exactly as they are. And if you're clicking task-to-task in the grid, your explicit tab choice still wins (the current sub-route is preserved)

[dsuhinin]

ok, I think now description should be fully up to date.

[uranusjr]

I would suggest dropping the Russian translation files. Most reviewers we have don’t read Russian, so bundling those changes in the same PR will significantly drag out the review process until we can find someone to review those parts. It would be better if this only touches the actual UI changes (and the en file, which is needed), and submit the translation changes in a later PR.

[dsuhinin]

I would suggest dropping the Russian translation files. Most reviewers we have don’t read Russian, so bundling those changes in the same PR will significantly drag out the review process until we can find someone to review those parts. It would be better if this only touches the actual UI changes (and the en file, which is needed), and submit the translation changes in a later PR.

sure, removed it already.