frontend: make the app's state addressable through routes

[rafaellehmkuhl]

Context

Almost nothing the user can open from the interface is addressable. The router (src/router/index.ts) declares three routes — /, /mission-planning and /about — while every menu reachable from the UI lives in in-memory state:

• The twelve settings pages and the four tools pages are components swapped inside the main menu through interfaceStore.currentSubMenuName / currentSubMenuComponentName (src/stores/appInterface.ts, wired in src/components/MainMenu.vue), so /settings/video or /tools/data-lake simply do not exist.
• Interface edit mode is a boolean (widgetStore.editingMode), toggled from the same menu.
• About is opened as a dialog (openAboutDialog in src/components/MainMenu.vue) even though an /about route already exists — the same destination is reachable two different ways, and only one of them is a URL.

The practical cost is that we can never point anyone at a place in the app. Support answers, docs, dialogs and warnings all degrade into click-by-click instructions ("open the main menu, go to Settings, then Video, scroll down to..."), a reload drops the user back to the flight view, and no settings page can be bookmarked or shared. It also blocks the more useful direction: a warning that offers a button taking the user straight to the setting that fixes it, instead of describing the path to it.

Proposal

Make the menus the user can reach from the interface live in the route, and have the store follow the route rather than the route being decorative.

• Real routes for the settings and tools pages, derived from the existing SubMenuName / SubMenuComponentName enums, so the enum stays the single source of truth for the page list.
• Keep the main menu in sync with the route in both directions: opening a page changes the route, and entering with a route opens the corresponding menu with that page selected.
• Settle the About duplication: one destination, reachable one way.
• Once places are addressable, use them: dialogs, snackbars and info elements get a button that navigates to the relevant page instead of a paragraph explaining how to reach it.

Still to define

• Whether interface edit mode belongs in the URL at all, or stays a mode toggle on top of whatever route is active.
• How hash vs. web history differences between Lite (createWebHashHistory) and Standalone (createWebHistory) affect the links we hand out — a link that works in one build should not break in the other.
• What back/forward should do: close the settings page, step through visited settings pages, or leave history alone.
• Whether it is worth exposing a small set of documented deep links as a stable contract (for docs and for BlueOS to link into), separate from internal route paths we may rename.