feat(directory): run sync as a retryable background job

[WhiteMuush]

What

Moves directory sync out of the request cycle into a retryable job queue. Closes #54.

Why

syncDirectoryConnection was awaited inside POST /api/directory/[id]/sync: large directories risk an HTTP timeout, and a failure left no retry or recovery.

How

• SyncJob table (status, attempts, maxAttempts, lastError, runAfter, timestamps) + migration.
• Enqueue: the route scopes the connection to the caller's company (404 otherwise), enqueueSyncJob dedups against a pending/running job, and the handler returns 202 with the job id instead of blocking.
• Processing: processSyncJobs claims due jobs with FOR UPDATE SKIP LOCKED (safe across instances), runs the sync, and on failure retries with exponential backoff (30s → 60s → 120s) up to maxAttempts, then marks FAILED.
• The route kicks the queue fire-and-forget; a scheduler (Add a periodic scheduler (auto scan + sync) #53) can also drain it. Concurrency is now enforced by the job claim, which supersedes the in-request advisory lock from Replace in-memory lock with pg_advisory_lock #55.

Tests

backoffMs, enqueue dedup vs create, and processSyncJobs success / re-queue-with-backoff / exhausted-FAILED paths; updated route tests (auth, 404 scoping, 202 + job id).

Notes

• Migration authored by hand (no local DB in this environment); prisma validate passes and the client generates cleanly. Run prisma migrate deploy on deploy.
• The fire-and-forget kick relies on a long-running node server; serverless deployments should rely on the scheduler to drain the queue.

Closes #54

🤖 Generated with Claude Code