Proposal: evaluate Trigger.dev for durable background tasks

From the PR description

Summary

Adds a discussion-only proposal to evaluate Trigger.dev for durable background work, with OCR as the first candidate.

Why / Motivation

Current OCR work begins asynchronously in the API process. A restart or deploy can interrupt it, and CPU-intensive OCR competes with request handling. This PR asks maintainers whether a durable task runner is an appropriate direction before proposing implementation.

Changes

• Adds docs/proposals/trigger-dev-background-tasks.md.
• Documents the proposed OCR-first scope, expected task boundaries, privacy/operational questions, alternatives, and feedback requested.
• Makes no application, dependency, configuration, or runtime changes.

Tradeoffs & risks

Trigger.dev would add a third-party execution environment for legal-document processing. Data-processing terms, worker region, log retention/redaction, system dependency packaging, cost, and document deletion/version semantics need agreement before implementation. A dedicated worker backed by a database queue remains a viable alternative.

How verified

Reviewed the proposal for scope and consistency with the existing OCR flow. No build or test was run because this is documentation-only and changes no executable behavior.

Feedback requested

1. Is a managed external task runner acceptable for document-processing workloads?
2. Is OCR the right first task?
3. What privacy, residency, and observability requirements would be required?
4. Would a dedicated self-managed worker/queue be preferred?

Checklist

• Reviewed the proposed change and kept it focused.
• No secrets, API keys, real documents, or .env files are included.
• No code, dependencies, configuration, or user-facing behavior is changed.
• Ran the relevant build/test command (not applicable to this documentation-only proposal).