perf(webapp,database): index the newest-task-version lookup (#4518)

Implementing PlanetScale Insights improvement.

## Summary

Validating a schedule (creating or updating one through the API or the
dashboard, and deploying a project that declares schedules) looks up the
newest version of a task by slug. That lookup reads *every* version of
the task and sorts them to return one. A project gains a row per task on
every deploy, so the work grows with the project's age: the oldest
projects pay the most, and dev-mode redeploys make it worse. This was
picked because it was the largest single consumer of database time on
the schedules path, and the fix is a sort key with no index behind it.

## Fix

`BackgroundWorkerTask` is indexed on `(projectId, slug)`, which serves
the equality but not the `ORDER BY createdAt DESC`. Postgres seeks the
index, then bitmap-scans and top-N sorts the whole group to produce a
single row. Adding `createdAt` to the index lets it scan backward and
stop at the first row.

The same call site also selected all 21 columns, including five JSON
blobs, to read one field (`triggerSource`), so it now selects that field
alone.

## Benchmark

Local Postgres 17, 997,000 seeded rows / 748 MB, group sizes chosen to
match the distribution seen in production.

| Group size | Before | After |
| --- | --- | --- |
| 15,000 versions of one task | 11.118 ms, 1,510 buffers, 15,000 rows
scanned | 0.027 ms, 4 buffers, 1 row |
| 2,000 versions of one task | 2.081 ms, 1,455 buffers, 2,000 rows
scanned | 0.022 ms, 4 buffers, 1 row |

```
before:  Limit -> Sort (top-N heapsort) -> Bitmap Heap Scan
after:   Limit -> Index Scan Backward using BackgroundWorkerTask_projectId_slug_createdAt_idx
```

An ascending index scanned backward is enough here, so no descending
index is needed.

## Impact and risk

Real-world gain lands between the two rows above and scales with how
many deploys a project has accumulated. Projects with few deploys will
see little change, since there is barely anything to sort.

The new index costs noticeably more than the existing two-column one: 43
MB against 7.3 MB on the benchmark rig. Adding `createdAt` makes every
key unique, which defeats btree deduplication, so this is a real disk
and write cost rather than a rounding error. Writes to this table happen
at deploy time, not on the run path, so the write amplification is
acceptable. The existing `(projectId, slug)` index is now a redundant
prefix and could be dropped, but this PR keeps it so index usage can be
observed before removing it.

Behavior is unchanged: same predicate, same ordering, same row returned.
The narrowed select is the only code change, and the field it keeps is
the only one the caller read.

Deploy note: the migration is
`20260806100000_add_background_worker_task_project_id_slug_created_at_index`
and uses `CREATE INDEX CONCURRENTLY IF NOT EXISTS`, so it can be
pre-applied by hand before the deploy.

.server-changes/faster-schedule-validation-lookup.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: improvement
+---
+
+Creating or updating a schedule, and deploying a project with declarative schedules, is faster in long-lived projects with many deploys.

apps/webapp/app/v3/services/checkSchedule.server.ts

@@ -45,6 +45,9 @@ export class CheckScheduleService extends BaseService {
         slug: schedule.taskIdentifier,
         projectId: projectId,
       },
+      select: {
+        triggerSource: true,
+      },
       orderBy: {
         createdAt: "desc",
       },

internal-packages/database/prisma/migrations/20260806100000_add_background_worker_task_project_id_slug_created_at_index/migration.sql

@@ -0,0 +1 @@
+CREATE INDEX CONCURRENTLY IF NOT EXISTS "BackgroundWorkerTask_projectId_slug_createdAt_idx" ON "public"."BackgroundWorkerTask"("projectId", "slug", "createdAt");

internal-packages/database/prisma/schema.prisma

@@ -752,6 +752,7 @@ model BackgroundWorkerTask {
   @@unique([workerId, slug])
   // Quick lookup of task identifiers
   @@index([projectId, slug])
+  @@index([projectId, slug, createdAt])
   @@index([runtimeEnvironmentId, projectId])
   @@index([runtimeEnvironmentId, slug, triggerSource])
 }