feat: filter by Sold / Not sold / All on the storefront and the admin (#105)

Three decisions were taken before any code, and are recorded on the issue.

The status filter is generalised to accept several values rather than gaining a second `sold` dimension beside it. "Not sold" is not a status: it is available-or-reserved on the storefront and includes pending in the admin, neither of which is one value. `?status=available,reserved` and `i.status = ANY($n::text[])` express that with one concept, so there is no way to write a contradiction like `?status=sold&sold=no`. A single status still parses to a list of one, which is how the admin's existing `?status=sold` keeps working untouched.

The storefront now defaults to Not sold. That is a change in what every customer sees, not just a new control: the black SOLD ribbons leave the default view on a catalogue where they were evidence the shop sells things, and every storefront link shared so far quietly changes meaning. Accepted deliberately, with the default named in STOREFRONT_DEFAULT_STATUSES rather than implied by the absence of a parameter.

The admin's four-way status dropdown is replaced rather than joined. That gives up isolating a single status: there is no longer a way to view only Reserved, or only Pending, and Not sold folds pending in with the rest. The pending workflow from #90 is the likeliest thing to miss it, and if it does, the fix is to put isolation back beside the preset rather than to remove the preset. The e2e test that covered "which is how Reserved is reached" is renamed and narrowed to what survives, rather than deleted.

One thing the issue did not anticipate, found by a test rather than by reading. The favorites view deliberately showed sold favorites - "a favorite that has just sold is often exactly what the customer came to look at", and they have just been emailed to say so. Defaulting the storefront to Not sold reversed that silently and broke the test asserting it. Favorites therefore keep their own default of everything, on the server and in the control's displayed position, while an explicit ?status= still wins. That interaction is the kind a single-feature change quietly breaks, and it was caught only because the previous decision had been written down as an assertion.

"All" still means different things in the two places, as the issue set out: available + reserved + sold on the storefront, all four in the admin. Pending remains unreachable from every public read - the storefront's unconditional exclusion clause is untouched - and the pending guard now checks every requested status rather than a single one, so `?status=available,pending` is refused for naming pending at all rather than accepted because the first name happened to be allowed.

The control sits in the filter bar rather than in the drawer, since the default now hides sold pieces and a customer who never opens the drawer would otherwise have no way to know they exist. It is consequently excluded from the "Filters (N)" count, which describes the drawer, while still counting toward hasActiveFilters so that an empty result reads as "no items match these filters" with a way out rather than as an empty shop.

Verification: 13 integration tests covering the default, each preset, the favorites exception and its override, and pending's unreachability under every accepted combination; 38 parser unit tests including multi-value parsing, an unknown name in a list being refused rather than dropped, and a list that names nothing; 6 new end-to-end tests for the storefront control, its URL round-trip, and the default staying out of the URL. 204 backend unit tests and 76 integration tests across the four affected suites pass. Two full end-to-end runs: 110 and 111 passing against the same 3 pre-existing failures, one run also showing a pending-publish failure that passes in isolation and did not recur - the cross-suite database contention filed as #116. tsc, ESLint and the production build are clean.

Closes #105
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/src/filters.ts

@@ -7,15 +7,69 @@ export interface ItemFilters {
   tagIds: number[];
   minPriceCents: number | null;
   maxPriceCents: number | null;
-  // Only the admin Inventory tab sets this; the storefront leaves it null and
-  // shows every status, as it always has.
-  status: ItemStatus | null;
+  // Several statuses, because the control this serves is not a status filter:
+  // "Not Sold" is available-or-reserved on the storefront and includes pending
+  // in the admin, neither of which is one value.
+  //
+  // Null means "no preference", which each side turns into its own default -
+  // Not Sold on the storefront, every status in the admin. Keeping the default
+  // as null rather than as an explicit list is what keeps it out of the URL and
+  // out of the active-filter count.
+  status: ItemStatus[] | null;
   // Storefront only, and only meaningful when signed in. Sold favorites are
   // included: the storefront shows sold items everywhere else, and a favorite
   // that has just sold is often exactly what the customer came to look at.
   favoritesOnly: boolean;
 }
 
+// The three-way control both screens offer. It is a preset over the status
+// list rather than a filter of its own, so there is only ever one dimension and
+// no way to express a contradiction like "sold and not sold".
+export type SaleState = 'sold' | 'not-sold' | 'all';
+
+// The same three words mean different sets in the two places, which is worth
+// stating twice rather than sharing one table that would be wrong for one of
+// them. Pending is excluded from every public read regardless of filter, so on
+// the storefront "All" cannot and must not include it — a label promising more
+// than it delivers.
+export const STOREFRONT_SALE_STATUSES: Record<SaleState, ItemStatus[]> = {
+  'not-sold': ['available', 'reserved'],
+  sold: ['sold'],
+  all: ['available', 'reserved', 'sold']
+};
+
+// In the admin, Not Sold includes pending: an item awaiting publication has
+// certainly not been sold, and hiding it from the default view would hide the
+// items most likely to need attention.
+export const ADMIN_SALE_STATUSES: Record<SaleState, ItemStatus[]> = {
+  'not-sold': ['available', 'reserved', 'pending'],
+  sold: ['sold'],
+  all: ['available', 'reserved', 'sold', 'pending']
+};
+
+function isPublicStatus(value: string): value is ItemStatus {
+  return value === 'available' || value === 'reserved' || value === 'sold';
+}
+
+const sameSet = (a: readonly string[], b: readonly string[]) =>
+  a.length === b.length && [...a].sort().join() === [...b].sort().join();
+
+// Which preset a status list corresponds to, for showing the control's current
+// position. Null means no preference, which each screen renders as its default.
+// A list matching none of the three - only reachable by hand-editing the URL -
+// reports as the default rather than leaving the control blank.
+export function saleStateFromStatuses(
+  statuses: ItemStatus[] | null,
+  table: Record<SaleState, ItemStatus[]>,
+  fallback: SaleState = 'not-sold'
+): SaleState {
+  if (statuses === null) return fallback;
+  const match = (Object.keys(table) as SaleState[]).find((state) =>
+    sameSet(statuses, table[state])
+  );
+  return match ?? fallback;
+}
+
 export const EMPTY_FILTERS: ItemFilters = {
   categoryId: null,
   tagIds: [],
@@ -34,7 +88,7 @@ export function filtersToSearchParams(filters: ItemFilters): URLSearchParams {
   if (filters.tagIds.length) params.set('tags', filters.tagIds.join(','));
   if (filters.minPriceCents !== null) params.set('min_price', String(filters.minPriceCents));
   if (filters.maxPriceCents !== null) params.set('max_price', String(filters.maxPriceCents));
-  if (filters.status !== null) params.set('status', filters.status);
+  if (filters.status !== null) params.set('status', filters.status.join(','));
   if (filters.favoritesOnly) params.set('favorites', '1');
   return params;
 }
@@ -58,10 +112,19 @@ export function filtersFromSearchParams(params: URLSearchParams): ItemFilters {
   // fail. The admin's status filter holds its value in React state and never
   // round-trips through this function, so it is unaffected. Do not "complete"
   // this list to match the type.
+  //
+  // A list containing anything unreadable yields null - the default - rather
+  // than the readable subset, so a mangled link falls back to a view that is
+  // explainable instead of one silently narrower than it looks.
   const rawStatus = params.get('status');
-  const status = rawStatus === 'available' || rawStatus === 'reserved' || rawStatus === 'sold'
-    ? rawStatus
-    : null;
+  const parsedStatus = (rawStatus || '')
+    .split(',')
+    .map((part) => part.trim())
+    .filter((part) => part !== '');
+  const status =
+    parsedStatus.length > 0 && parsedStatus.every(isPublicStatus)
+      ? (parsedStatus as ItemStatus[])
+      : null;
 
   const favorites = params.get('favorites');
 
@@ -77,18 +140,27 @@ export function filtersFromSearchParams(params: URLSearchParams): ItemFilters {
 
 // One count for the "Filters (N)" button. A price range counts once however
 // many ends are set, since it reads as a single filter to the user.
+//
+// Status is deliberately not counted. It has its own always-visible control
+// beside this button rather than living in the drawer, so counting it would put
+// a number on a button whose drawer shows nothing set — and the control already
+// displays its own position.
 export function activeFilterCount(filters: ItemFilters): number {
   let count = 0;
   if (filters.categoryId !== null) count++;
   count += filters.tagIds.length;
   if (filters.minPriceCents !== null || filters.maxPriceCents !== null) count++;
-  if (filters.status !== null) count++;
   if (filters.favoritesOnly) count++;
   return count;
 }
 
+// Broader than the count above, and intentionally so: this decides whether an
+// empty result reads as "no items match these filters" with a way out, or as an
+// empty shop. A status filter that matched nothing is exactly the case where
+// that distinction matters, so it counts here even though it is not in the
+// drawer's tally.
 export function hasActiveFilters(filters: ItemFilters): boolean {
-  return activeFilterCount(filters) > 0;
+  return activeFilterCount(filters) > 0 || filters.status !== null;
 }
 
 export interface CategoryNode extends Category {