fix(worker): a terminal write to a dropped schema drops the task instead of the worker

[cdbartholomew]

Fixes #5811.

Problem

Deleting a tenant drops its schema, async_operations included. A task still in flight then fails every terminal status write with "relation does not exist". _write_terminal treated that the same as an unreachable database:

• it retried for TERMINAL_WRITE_DEADLINE_S (300 s);
• then it SIGTERMed the worker, taking every other in-flight task on that process down with it;
• the purpose was to let restart recovery hand back the row, but that row no longer exists.

In a combined API + worker process the API goes down too. A suite that deletes organizations while async work is in flight then fails partway through with ECONNREFUSED.

Fix

Before retrying, a failed terminal write is now checked. If both of these hold:

1. the error says a table or schema does not exist (Postgres 42P01/3F000, Oracle ORA-00942, found anywhere in the exception chain), and
2. a read of the task's own operations table fails the same way,

then the row is gone with its schema. The write is abandoned with a warning, and the worker keeps running.

The existing retry-then-exit path is kept in two cases, so real DB outages are still covered (#3228, #5377):

• A missing table elsewhere in the write. The row is still there and could be a real bug to surface.
• A probe that fails for any other reason. That isn't proof the schema is gone.

Tests

tests/test_worker.py::TestTerminalWriteToADroppedSchema:

• Dropped schema: returns without exiting. This test fails without the fix, because the worker exits.
• Missing table while the operations table exists: still shuts the worker down.
• Unreachable DB: still shuts the worker down.
• The missing-relation check: sees through exception wrapping and recognises the Oracle code.

tests/test_worker.py: 146 passed. ruff check and ruff format are clean on the changed files.