Delivery worker should refuse startup on schema mismatch

[quangshuynh]

Problem

The worker operations documentation states that the delivery worker
performs the same startup schema check as the API and refuses to run
when the database schema does not match the revision expected by the
current build.

The worker does not currently perform that check. It creates the
database engine and enters the polling loop without calling the existing
verify_schema function.

This creates an operational correctness problem: a new worker can start
against an unmigrated database, remain alive from a process-supervisor
perspective, and repeatedly fail delivery batches instead of refusing
startup with a clear schema-mismatch error.

Why it matters

Forms relies on explicit migration discipline and documents a deployment
order of stopping old processes, applying migrations, and then starting
new processes. The API already enforces this boundary. The worker should
enforce the same invariant.

A schema mismatch should be detected before the worker begins polling
rather than surfacing repeatedly as ordinary batch failures.

Acceptance criteria

• The worker verifies the database schema after creating the
  engine and before entering the poll loop.
• A schema mismatch causes the worker to refuse startup and exit
  non-zero.
• The existing operator-facing schema mismatch message is reused
  where appropriate.
• The database engine is disposed on the refusal path.
• Automated tests cover worker startup against a mismatched
  schema.
• Existing poll-loop tolerance for transient batch failures
  remains unchanged.
• The existing worker operations documentation accurately
  describes the resulting behavior.

Non-goals

• Automatic migrations on worker startup.
• Changes to the worker polling/retry loop.
• A second schema-verification implementation.
• Changes to the existing verify_schema semantics.