Refactor world-postgres queue execution away from loopback HTTP

[NathanColosimo]

Summary

@workflow/world-postgres currently executes Graphile jobs by POSTing back into the app workflow HTTP route. That kept Next production route registration correct after #1417, but #2656 shows the loopback transport can consume jobs before the local server is reachable.

Proposal

Retry the #1334 direction, but keep the implementation small: let Postgres own the queue-handler wrapper it needs, register the generated workflow handler in-process, and have Graphile call that handler directly. Durable delays and retries should stay in Graphile, and the code should not reintroduce a dependency on @workflow/world-local for queue execution.

Context

• Symptom: world-postgres should not consume loopback jobs before the executor is reachable #2656
• Prior direct attempt: refactor(world-postgres): execute Graphile jobs directly with durable rescheduling #1334
• HTTP-only revert/fix: fix(world-postgres): route Graphile queue execution over workflow HTTP endpoints #1417

Acceptance criteria

• Graphile workers do not need WORKFLOW_LOCAL_BASE_URL, PORT, or loopback fetch to execute workflow messages.
• The returned HTTP handler still works for framework route requests and health checks.
• Delayed re-execution remains durable via Graphile runAt jobs.
• The old fix(world-postgres): route Graphile queue execution over workflow HTTP endpoints #1417 production failure mode is covered by tests or made impossible by the current combined route registration path.
• The final diff removes more Postgres/local coupling than it adds.