Order state transitions follow valid sequence

Without application-layer transition guards, any code path — including a customer-facing API route — can write an arbitrary status value to any order. An attacker who discovers the order update endpoint can skip 'confirmed' and 'shipped' to mark their own order 'delivered', triggering fulfillment or refund logic without a real purchase completing the intervening steps. Even without malice, a race condition or a bug in an admin tool can jump an order from 'pending' to 'delivered' in one call, corrupting history and triggering incorrect emails. A database enum constraint alone (CWE-841) does not prevent logically invalid sequences — application-layer guards must enforce the allowed graph.

Implement an explicit transition map in lib/orders/state-machine.ts and route every status update through it. All direct db.orders.update() calls that change status must be replaced with transitionOrder().

// lib/orders/state-machine.ts
const ALLOWED_TRANSITIONS: Record<string, string[]> = {
  pending:   ['confirmed', 'cancelled'],
  confirmed: ['shipped', 'cancelled'],
  shipped:   ['delivered'],
  delivered: [],
  cancelled: [],
}

export async function transitionOrder(orderId: string, newStatus: string, actorId: string) {
  const order = await db.orders.findUniqueOrThrow({ where: { id: orderId } })
  const allowed = ALLOWED_TRANSITIONS[order.status] ?? []
  if (!allowed.includes(newStatus)) {
    throw new Error(`Invalid transition: ${order.status} → ${newStatus}`)
  }
  return db.orders.update({ where: { id: orderId }, data: { status: newStatus } })
}