Replace the check-in QR's signed token with a compact, indexed ticket hash

The door check-in QR currently encodes a signed token of about 93 characters (kind.uuid.expiry.HMAC), which makes a dense QR that is harder to scan, especially printed small on a ticket.

The check-in route requires the restricted "check in tickets" permission, so the action is permission-gated: the value in the QR is never a standalone bearer secret an outsider could exploit. It only needs to identify the booking or order uniquely and stably.

Proposal: add a compact, indexed, unique ticket_hash to the booking and the transaction (order) entities, generated in preSave as a short random base64url value, the most compact encoding that stays collision-free, with the unique index as the safety net. The QR carries a one-character kind prefix (b for a booking, o for an order) followed by the hash, about a dozen characters in all.

The columns are indexed on both entities for fast check-in lookups. The check-in resolver reads the prefix, loads the entity by its ticket_hash, and hands it to the existing handler. The guards stay unchanged (the permission, the booking state and the event-day window), so it stays as secure as today.

The signed check-in token is retired; the order-level ticket download link keeps its own separate signed token.

Pre-1.0, so the token-format break is acceptable. The base fields are installed with installFieldStorageDefinition and existing rows backfilled, with no update hook.

The scanner route path is also shortened (to /yykc) and the check-in URL is generated without a language prefix, since it is machine-scanned. Together the encoding drops the QR from about 49x49 to 33x33 modules, which stays scannable printed small even at a robust error-correction level.