fix(test): correct the sold-filter tally assertion stranded by #188 (#239)

main has been red since 2026-08-25. Every SonarQube run reported 147 passed, 1 failed, and it was this test every time — expected "Filters", received "Filters (1)".

The test is stale, not the code. It was last touched on 2026-08-23 in #137; the tally logic changed on 2026-08-25 in #188, which never touched the spec. #188 redefined the tally as the number of chips and moved the availability preset into the dimension system as a bar dimension — one that still emits a chip for any non-default status, deliberately, because without it `?status=reserved` is an empty grid with no Clear filters button and no way out but editing the URL. The test asserted the rule that held before that change.

Counting bar chips differently from drawer chips would restore exactly the per-screen special-casing #188 removed, and the drift it fixed was the admin's tally disagreeing with the storefront's. So the assertion moves, not the tally.

The replacement also checks the tally comes back down when the default is restored. The original only ever asserted one direction, which would pass against a count that incremented and never decremented — worth fixing while the test is open rather than leaving a second gap behind the first.

There is a real wart left standing: `Filters (1)` opens a drawer with nothing selected in it, because the filter it is counting lives in the bar. That is a cost of #188's design rather than a defect in it, and the comment now says so rather than leaving the next reader to rediscover it.

Verified by running the spec in isolation with a single worker: 6 passed.

Closes #239

frontend/tests/e2e/sold-filter.spec.ts

@@ -76,15 +76,28 @@ test.describe('Filtering the storefront by availability', () => {
     await expect(storefront.gridCell(NAMES.sold)).toHaveCount(0);
   });
 
-  // The control sits beside the Filters button rather than inside the drawer,
+  // Since #188 the tally is the number of chips, not the number of drawer
-  // so its state must not be counted as one of the drawer's filters.
+  // controls, so a bar dimension counts like any other. This test asserted the
-  test('does not inflate the Filters count', async ({ page, storefront }) => {
+  // older rule and went unnoticed for days because nothing updated it when that
+  // rule changed — see #239.
+  //
+  // The count and the chip row are deliberately the same number. Availability
+  // emits a chip for any non-default status so that ?status=reserved is not an
+  // empty grid with no Clear filters button, and counting bar chips differently
+  // from drawer ones would restore exactly the per-screen special-casing #188
+  // removed.
+  test('counts the availability preset in the Filters tally', async ({ page, storefront }) => {
     await storefront.goto();
     await storefront.chooseAvailability('Sold');
 
     // Matched loosely and asserted on the text, because antd's icon contributes
-    // its own aria-label to the button's accessible name. The text is the part
+    // its own aria-label to the button's accessible name.
-    // that would gain a "(1)" if status were counted as a drawer filter.
+    await expect(storefront.filtersButton).toHaveText('Filters (1)');
+
+    // The default earns silence: returning to it removes the chip, so the tally
+    // goes with it. Without this the test would pass on a tally that never
+    // decremented.
+    await storefront.chooseAvailability('Not sold');
     await expect(storefront.filtersButton).toHaveText('Filters');
   });
 });