Widen bulk_operations.status so partial bulk results can be recorded (#21)

Found while verifying #21 against the live schema: the model writes
'completed_with_errors' (21 chars) when a bulk operation finishes with
per-ticket failures, but bulk_operations.status was varchar(20), so the
write failed with "Data too long for column 'status'".

This was latent — bulk status changes previously forced every transition
through, so failed was always 0. Now that they honour the Workflow
Designer, a partially-skipped batch is a normal outcome and hits it.

- migrations/001 widens the column to varchar(32) (idempotent).
- The baseline is updated to match, for fresh installs.
- The bookkeeping UPDATE is wrapped in a try/catch: it runs after the
  ticket changes are committed, so an instance deployed ahead of its
  migrations must not turn a completed operation into an error response.

Verified against the live database with a disposable-ticket harness:
comment-required rejection changes nothing, undefined transitions are
refused per ticket with a reason, allowed transitions still work, mixed
batches apply the valid half, and an already-Closed ticket is a no-op.

migrations/000_baseline.sql

@@ -59,7 +59,8 @@ CREATE TABLE IF NOT EXISTS `bulk_operations` (
   `ticket_ids` text NOT NULL,
   `performed_by` int(11) NOT NULL,
   `parameters` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL CHECK (json_valid(`parameters`)),
-  `status` varchar(20) DEFAULT 'pending',
+  -- 32, not 20: 'completed_with_errors' is 21 chars (see 001_widen_bulk_operations_status.sql)
+  `status` varchar(32) DEFAULT 'pending',
   `total_tickets` int(11) DEFAULT NULL,
   `processed_tickets` int(11) DEFAULT 0,
   `failed_tickets` int(11) DEFAULT 0,