feat(catalog): record bulk edits, make deletions reversible, unify the tree read

A bulk offer edit is the catalog mutation that rewrites hundreds of rows at
once, and it was the only one writing nothing to the staff activity log: 22 of
the 43 catalog actions logged, this one did not. The entry it now writes says
what changed, not just that something did, because the log has no undo of its
own and "bulk updated 200 offers" cannot answer the question it exists for.

Deleting offers had no inverse at all. Every removed row is now kept at delete
time and the caller gets a restoreId back, so an accidental multi-select is a
click rather than a hand-edit of the table. The undo toast covers the common
case; a RecentDeletionsPanel holds the same records so a delete noticed later is
still reachable. Three refusals guard it: an id that another offer has since
taken, a category that no longer exists (which would leave an offer that sells
nowhere and shows under no page), and a delete whose restore record cannot be
written — that one rolls back rather than deleting without a way back. Reading
the audit row FOR UPDATE is also what stops two restores of one deletion from
both inserting.

sendCatalogUpdate() overwrote hotel-status.json on every write, so "which
imports reached the hotel" was answerable for the last attempt only, and a
failure two imports ago was gone by the time anyone looked. That file is now
also appended to as a bounded 50-entry tail.

The tree route carried four copies of the same page-select-plus-counts
shaping, of which the BC branches had already drifted: one counted offers
through the VARCHAR-tolerant helper, the other inline and swallowing errors.
All of it is one readPages() now, and readFullTree sends both catalogs through
one depth computation instead of delegating normal to getTreeFlat while
computing BC here — a split that left two implementations behind one function
name. getTreeFlat is gone. The BC ancestor walk also went from 20 levels to 50,
matching getAncestors, so a deeply nested catalog no longer loses its
breadcrumb.

Bulk editing reaches the BC catalog, which previously had no way to edit or
duplicate offers in bulk. The catalog is part of the operation identity now, so
replaying one request key against the other catalog is not mistaken for the
same work.

Integration tests failed to import: the next/cache mock supplied only
revalidatePath, and catalog-totals calls unstable_cache at module scope.

src/actions/catalog-items.ts

@@ -3,6 +3,12 @@
 import { eq, inArray, like, or, sql } from "drizzle-orm";
 import { revalidatePath } from "next/cache";
 import { offerPatchSchema } from "@/features/catalog/domain/offer-input";
+import { catalogFailure } from "@/features/catalog/server/errors";
+import {
+	deleteCatalogItemsCommand,
+	listRestorableDeletionsCommand,
+	restoreDeletedCatalogItemsCommand,
+} from "@/features/catalog/server/item-deletes";
 import {
 	createOfferCommand,
 	moveOffersCommand,
@@ -196,20 +202,88 @@ export async function bulkCreateCatalogItems({
 	});
 }
 
-export async function deleteCatalogItems({ ids }: { ids: number[] }) {
+/**
+ * Deleting offers is the one catalog mutation with no natural inverse, so the
+ * full rows are kept at delete time and `restoreId` is handed back. The UI shows
+ * that as an undo affordance; without it a mis-click is unrecoverable.
+ */
+export async function deleteCatalogItems({
+	ids,
+	requestKey,
+}: {
+	ids: number[];
+	requestKey?: string;
+}) {
 	const staff = await requirePermission(PERMS.CATALOG_EDIT);
-	return await withCatalogExport(async () => {
-		await db.delete(CatalogItems).where(inArray(CatalogItems.id, ids));
-		await sendCatalogUpdate();
-		await logStaffActivity({
-			staffId: staff.id,
-			action: "catalog_items_delete",
-			description: `Deleted catalog items: ${ids.join(", ")}`,
-			targetType: "catalog_item",
+	try {
+		return await withCatalogExport(async () => {
+			const data: {
+				deleted: number;
+				restoreId: number;
+			} = await deleteCatalogItemsCommand(ids, staff.id, requestKey);
+			await sendCatalogUpdate();
+			await logStaffActivity({
+				staffId: staff.id,
+				action: "catalog_items_delete",
+				description: `Deleted ${data.deleted} catalog offer(s): ${ids.join(", ")}`,
+				targetType: "catalog_item",
+			});
+			revalidatePath("/admin/catalog");
+			return { ok: true as const, data };
 		});
-		revalidatePath("/admin/catalog");
-		return { ok: true as const, data: {} };
-	});
+	} catch (error) {
+		const failure = catalogFailure(error);
+		return { ok: false as const, error: failure.message };
+	}
+}
+
+/**
+ * Recent deletions that are still restorable. The undo toast covers the common
+ * case; this is the fallback for a delete noticed after that toast is gone.
+ */
+export async function listRestorableCatalogItemDeletions() {
+	await requirePermission(PERMS.CATALOG_EDIT);
+	try {
+		return {
+			ok: true as const,
+			data: await listRestorableDeletionsCommand(),
+		};
+	} catch (error) {
+		const failure = catalogFailure(error);
+		return { ok: false as const, error: failure.message };
+	}
+}
+
+export async function restoreDeletedCatalogItems({
+	restoreId,
+	requestKey,
+}: {
+	restoreId: number;
+	requestKey?: string;
+}) {
+	const staff = await requirePermission(PERMS.CATALOG_EDIT);
+	try {
+		return await withCatalogExport(async () => {
+			const data: { restored: number } =
+				await restoreDeletedCatalogItemsCommand(
+					restoreId,
+					staff.id,
+					requestKey,
+				);
+			await sendCatalogUpdate();
+			await logStaffActivity({
+				staffId: staff.id,
+				action: "catalog_items_restore",
+				description: `Restored ${data.restored} deleted catalog offer(s)`,
+				targetType: "catalog_item",
+			});
+			revalidatePath("/admin/catalog");
+			return { ok: true as const, data };
+		});
+	} catch (error) {
+		const failure = catalogFailure(error);
+		return { ok: false as const, error: failure.message };
+	}
 }
 
 export async function moveCatalogItems({