perf(database): index PersonalAccessToken.userId so token lookups stop seq-scanning (#4588)

## Summary

The two personal-access-token lookups by `userId` (one also filtering
`revokedAt is null`, the other also filtering `name`) had no index on
`userId`, so each did a full sequential scan of the
`PersonalAccessToken` table to return a single row. `userId` is also an
unindexed foreign key.

## Fix

Add a single `@@index([userId])`. A user owns only a handful of PATs, so
once `userId` is indexed each lookup touches a few rows and the residual
`revokedAt` / `name` filter is trivial. Both query shapes lead with
`userId =`, so one index serves both and a composite would only add
write cost. The migration uses `CREATE INDEX CONCURRENTLY IF NOT
EXISTS`, which is online-safe under write load and reversible by
dropping the index.

Verified with a seeded local EXPLAIN: both queries go from a full
sequential scan to an index scan on the new index.

Author: ericallam

.server-changes/index-personal-access-token-user-id.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: improvement
+---
+
+Speed up personal access token lookups by indexing them on their owner

internal-packages/database/prisma/migrations/20260812140000_add_personal_access_token_user_id_index/migration.sql

@@ -0,0 +1 @@
+CREATE INDEX CONCURRENTLY IF NOT EXISTS "PersonalAccessToken_userId_idx" ON "public"."PersonalAccessToken"("userId");

internal-packages/database/prisma/schema.prisma

@@ -155,6 +155,8 @@ model PersonalAccessToken {
   updatedAt DateTime @updatedAt
 
   authorizationCodes AuthorizationCode[]
+
+  @@index([userId])
 }
 
 enum OrganizationAccessTokenType {