refactor(db): build the item queries through Kysely (#308)

The two queries the builder was ever wanted for. #294 removed interpolation from seven sites by hoisting each fixed-shape query into a named constant; these two genuinely composed their WHERE at run time and could not be fixed that way, which is why they are the last S2077 hotspots. They were safe, and itemFilters.ts spent sixteen lines explaining why — that the clause fragments are literals, that the only things interpolated into them are placeholder indices, and that every value goes onto params. That argument was correct and it was still an argument, guarded by a comment and two tests, on a route reachable without signing in.

All four call sites moved rather than only the two flagged ones. The by-id constants carried no hotspot, but they were built by interpolating the same projection strings the list queries used, so converting only the list queries would have left itemSelect.ts holding a Kysely builder and a raw string that had to produce an identical projection — two spellings to keep in step by hand where the file's own header already warned about one.

The second thing this buys may matter more than the first. pool.query<T> asserts a shape TypeScript never checks against the SQL, which is why that header said the selects and their row types are kept in step by hand and the integration suite was the only thing that caught a drop. The projections are built with jsonArrayFrom now, which emits the same coalesce(json_agg(agg), '[]') they hand-wrote, so the row type follows from the projection and a dropped column is a compile error.

The row types stay hand-written and exported rather than being inferred from the query. Inference would be tidier and is refused deliberately: these are the shape the frontend reads, and a type that silently becomes whatever the query happens to return is a contract that can change without anyone deciding to change it.

The two invariant tests survive and got stronger. They used to inspect the clause strings the builder returned; they now compile the expressions and assert on the SQL Kysely actually emits, with the hostile value appearing in the parameters and nowhere else — the same claim, tested against the real artefact instead of an intermediate one.

Closes #308

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

backend/src/routes/admin.ts

@@ -1,10 +1,10 @@
 import { Router, Request, Response } from 'express';
 import { PoolClient } from 'pg';
 import { pool, requireRow } from '../db';
-import { ADMIN_ITEM_SELECT, ADMIN_ITEM_BY_ID, AdminItemRow, ItemRecord } from '../itemSelect';
+import { adminItemQuery, AdminItemRow, ItemRecord } from '../itemSelect';
 import { ItemStatus } from '../types';
 import { asyncRoute } from '../asyncRoute';
-import { parseItemFilters, buildItemFilterSql, FilterError } from '../itemFilters';
+import { parseItemFilters, itemFilterExpressions, FilterError } from '../itemFilters';
 import { readId, tagColorFor } from '../utils';
 import { notifyFavoritersOfSale, notifyFavoritersOfRemoval, collectFavoriteRecipients } from '../favoriteAlerts';
 import { removeBackgroundsForItem, restoreOriginalsForItem } from '../intake/backgroundRemoval';
@@ -132,21 +132,22 @@ router.get('/items', asyncRoute(async (req: Request, res: Response) => {
     return res.status(400).json({ error: 'favorites is not a valid inventory filter' });
   }
 
-  // S2077 flags every query below that assembles its SQL as a template literal,
-  // and this is the one where that is more than a formality: `where` really is
-  // built at run time. What makes it safe is that buildItemFilterSql composes
-  // only string literals written in itemFilters.ts. The only interpolations
-  // inside any of them are placeholder indices — `$${next}`, and `$${next + 1}`
-  // in the tags clause — numbers, seeded from the startIndex argument and
-  // incremented locally. Neither is ever derived from a filter value.
-  //
-  // So a caller chooses which of six fixed fragments are joined, and supplies
-  // every value in `params`, and neither of those becomes SQL. parseItemFilters
-  // rejects malformed input above, but that is defence in depth rather than the
-  // reason this holds — the clause literals would be safe without it.
-  const { clauses, params } = buildItemFilterSql(filters, 1, null);
-  const where = clauses.length ? `WHERE ${clauses.join(' AND ')}` : '';
-  const { rows } = await pool.query<AdminItemRow>(`${ADMIN_ITEM_SELECT} ${where} ORDER BY i.created_at DESC`, params);
+  // No interpolation, and nothing to argue about. Until #308 this assembled
+  // `${ADMIN_ITEM_SELECT} ${where}` from clauses composed at run time, and
+  // sixteen lines in itemFilters.ts explained why that was safe. The clauses
+  // are Kysely expressions now: a value cannot reach the SQL text, because the
+  // types do not let it.
+  // `.$castTo` narrows `status` from the schema mirror's generic `string` (the
+  // column is a CHECK-constrained text column, not a native Postgres enum, so
+  // kysely-codegen has no literal union to give it) to the app-level
+  // `ItemStatus` the CHECK constraint actually enforces. Every other field on
+  // AdminItemRow already matches the projection without a cast.
+  const rows: AdminItemRow[] = await adminItemQuery()
+    .where((eb) => eb.and(itemFilterExpressions(eb, filters, null)))
+    .orderBy('i.created_at', 'desc')
+    .$castTo<AdminItemRow>()
+    .execute();
+
   res.json(rows);
 }));
 
@@ -175,7 +176,7 @@ router.post('/items', uploadImages, asyncRoute(async (req: Request, res: Respons
     // is bound as $1. It always was bound — what changed is that a reader no
     // longer has to check that the interpolated half carries no caller data,
     // because there is no interpolated half. See #294.
-    const { rows: full } = await pool.query<AdminItemRow>(ADMIN_ITEM_BY_ID, [item.id]);
+    const full = await adminItemQuery().where('i.id', '=', item.id).execute();
     res.json(requireRow(full, 'the item just inserted'));
   } catch (err) {
     await client.query('ROLLBACK');
@@ -229,7 +230,7 @@ router.put('/items/:id', uploadImages, asyncRoute(async (req: Request, res: Resp
     // The same constant as the create route above. itemId is caller-controlled
     // and goes through the driver as a bound parameter; it never reaches the
     // query text.
-    const { rows: full } = await pool.query<AdminItemRow>(ADMIN_ITEM_BY_ID, [itemId]);
+    const full = await adminItemQuery().where('i.id', '=', itemId).execute();
     // The create route beside this one has always used requireRow here. This
     // one did not, so an UPDATE matching nothing committed happily, the SELECT
     // returned nothing, and the caller got 200 with an empty body — a success