fix(shell): publish the active view, so both navs follow the back path

The nav components learned where the user was from the `navigate`
CustomEvent, which only the outbound path dispatches: `popstate` calls
`handleNavigate()` directly. So a back-navigation left both of them
highlighting the view just left — desktop included, at any width, on
any back across two primary views. Opening a detail view was the same
cause wearing a different symptom: `app-sidebar` guarded on its own
item list and kept its highlight, `bottom-nav` did not and lit nothing.

It cannot be fixed by re-dispatching `navigate` — `index.ts` is that
event's document listener, so that is an infinite loop, and "please go
to X" is not the statement being made. `activeViewStore` is the shell
saying "the active view is now X", once per navigation, `popstate`
included; both navs read it through a controller and hold no
`activeView` of their own.

A store rather than an event because a component that mounts *after* a
navigation still has to know: `bottom-nav`'s drawer builds its
`app-sidebar` on open, and that copy had heard nothing at all, so the
drawer opened on Home from any page in the app.

Closes #72

frontend/index.ts

@@ -40,6 +40,7 @@ import { setBasePath } from '@awesome.me/webawesome/dist/webawesome.js';
 import { registerBundledIcons } from './src/icons';
 import { queueStore } from '@store/queue-store';
 import { searchStore } from '@store/search-store';
+import { activeViewStore } from '@store/active-view-store';
 import * as Player from '@go/player/player.js';
 import * as Queue from '@go/queue/queue.js';
 import { GetDefaultPage } from '@go/config/config.js';
@@ -279,6 +280,20 @@ async function handleNavigate(
     // attribute keeps e2e selectors semantic instead of structural.
     mainContent.dataset.activeView = view;
 
+    // And publishing it as a *value* is what the nav components read.
+    // They used to learn the active view from the `navigate` event,
+    // which only the outbound path dispatches -- so a back-navigation
+    // left both of them highlighting the view it had just left (#72).
+    // Re-dispatching `navigate` here is not the fix: this file is a
+    // document listener for it, so that is an infinite loop, and
+    // "please go to X" is not the statement being made.
+    //
+    // `view in VIEW_TAGS` is the primary/detail split, and it is passed
+    // rather than re-derived because this table is where it is written
+    // down.  A detail view therefore leaves the tab it was opened from
+    // lit, which is what the report asks for.
+    activeViewStore.setView(view, view in VIEW_TAGS);
+
     // --- Primary (cacheable) views ----------------------------------------
     if (view in VIEW_TAGS) {
         // Remove any active detail view first