Cancellation updates order status and creates history entry

A cancellation that only flips the status field leaves no durable record of who cancelled, when, or why. This is a CWE-778 gap and a GDPR Art. 5(1)(f) issue: processing activities must be accountable, and 'the order is cancelled' with no supporting event log is not accountable. Without a history entry, support staff cannot determine whether the cancellation was customer-initiated or admin-initiated, and refund disputes have no audit anchor. Both writes — status update and history entry — must be atomic in a transaction; a non-transactional write creates a race condition where one operation can succeed and the other fail.

Route all cancellations through the shared transitionOrder function in lib/orders/state-machine.ts, which handles both the status update and history entry atomically. Remove any direct db.orders.update() calls in cancellation handlers.

// Replace in app/api/orders/[id]/cancel/route.ts:
// WRONG:
await db.orders.update({ where: { id: orderId }, data: { status: 'cancelled' } })

// CORRECT:
await transitionOrder(orderId, 'cancelled', actorId, 'Customer requested cancellation')
// transitionOrder wraps both writes in a db.$transaction