fix(timetable): widen artist_engagements.portal_token to varchar(64)

PortalTokenController stores hash('sha256', \$plainToken) — a 64-char
hex digest. RFC v0.2 §5.3's "ULID unique nullable" annotation is loose;
in practice the column holds a hash, not a ULID. char(26) silently
truncates under MySQL strict mode (1406 Data too long) — surfaced
when PortalTokenSecurityTest exercised the auth path against the new
schema. Widen to varchar(64) to fit the hash.

Schema dump regenerated against crewli_test.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

api/database/migrations/2026_05_08_100006_create_artist_engagements_table.php

@@ -44,8 +44,11 @@ return new class extends Migration
             $table->datetime('advance_open_from')->nullable();
             $table->datetime('advance_open_to')->nullable();
 
-            // Portal access
-            $table->ulid('portal_token')->nullable()->unique();
+            // Portal access. Stored as hashed token (sha256 hex, 64 chars).
+            // RFC v0.2 §5.3 says "ULID unique nullable"; in practice the
+            // PortalTokenController hashes the plain token and stores the
+            // 64-char hex digest. Widen the column to fit.
+            $table->string('portal_token', 64)->nullable()->unique();
 
             // Advancing aggregates (recomputed in Session 3)
             $table->integer('advancing_completed_count')->default(0);