test(e2e): cover configurable destinations; stop assuming a nav item

The assertions are about the navigation, not about the setting: "the
config was saved" is the plumbing, and #69 and #72 both shipped green
under specs that measured exactly that.

Four existing specs reached a view by clicking its nav item, which since
this change is not guaranteed to exist -- Autotag is hidden by default
and Downloads is absent without a download client -- so they timed out
waiting for a locator that will never resolve. `navigateTo` dispatches
the app's own `navigate` event, which is what every nav item, card and
detail view dispatches, so it is the mechanism rather than a test-only
door. Click the item when the nav is the subject.

Closes #25

e2e/specs/view-lifecycle.spec.ts

@@ -4,6 +4,7 @@ import {
   eventNames,
   resetEvents,
   waitForEvent,
+  navigateTo,
 } from '../support/fixtures.js';
 
 /**
@@ -39,7 +40,9 @@ test.describe('view lifecycle', () => {
   test('a keypress on Settings does not reach the Autotag queue', async ({
     app,
   }) => {
-    await app.getByTestId('nav-autotag').click();
+    // By event, not by nav item: Autotag is hidden by default (#25)
+    // and a hidden view is still reachable.
+    await navigateTo(app, 'autotag');
     await expect(app.getByTestId('main-content')).toHaveAttribute(
       'data-active-view',
       'autotag',
@@ -83,7 +86,9 @@ test.describe('view lifecycle', () => {
     // The other half of the same bug (H-2): two document keydown handlers
     // with no arbitration meant `s` on this page skipped the album *and*
     // toggled shuffle.  As a panel binding it can only mean one thing.
-    await app.getByTestId('nav-autotag').click();
+    // By event, not by nav item: Autotag is hidden by default (#25)
+    // and a hidden view is still reachable.
+    await navigateTo(app, 'autotag');
     await expect
       .poll(() => pendingCount(app))
       .toMatch(/^Pending \(\d+\)$/);