Deflake the upsert suite teardown against in-flight background jobs (#24804)

## Context

The server-integration-test shard 10 flakes intermittently in
`upsert.integration-spec.ts` with a postgres deadlock (40P01) during
fixture teardown, thrown from `DeleteIndexActionHandlerService` via
`deleteManyObjectMetadatas`. It hit two unrelated PRs on 2026-08-25 and
passed on rerun both times.

## Root cause

The record mutations in the test body enqueue background jobs (timeline
activity, audit log). The suite's `afterEach` deletes the test object,
but jest runs inner `afterEach` hooks before the global wait-for-jobs
hook from `setup-wait-for-all-jobs-between-tests.ts` (registered via
`setupFilesAfterEnv`, so outermost). The deletion migration could
therefore race a job still inserting rows referencing the object:

- the migration transaction takes AccessExclusiveLocks across the object
table and the related tables carrying its join columns
(timelineActivity, favorite, attachment, ...)
- the job's insert holds a write lock on its own table and waits on the
object table for its implicit foreign key check (RowShareLock)

Postgres detects the cycle and kills the migration as the deadlock
victim.

## What this does

Wait for all jobs to finish at the top of the suite's `afterEach`,
before touching the object metadata, so the deletion never overlaps the
jobs its own tests enqueued. The sibling composite-unique-index suite
tears down in `afterAll`, which already runs after the global wait, so
it is not affected.

The same race also exists in production (background jobs vs a user
deleting an object), where no wait is possible; a server-side retry for
that case was proposed in #24807 and closed.

## Verification

Full `upsert.integration-spec.ts` run against a freshly reset test
database passes (7 tests).