world-postgres: maxAttempts is hardcoded to 3, so the retry budget cannot be tuned

Package: @workflow/world-postgres@4.3.0

Question rather than a defect

Every step job is enqueued with a fixed attempt cap (dist/queue.js:114):

await utils.addJob(getJobQueueName(queuePrefix), MessageData.encode({ ... }), {
  ...(jobKey ? { jobKey } : {}),
  ...(runAt ? { runAt } : {}),
  maxAttempts: 3,
});

PostgresWorldConfig exposes connectionString, jobPrefix, queueConcurrency, maxPoolSize and streamFlushIntervalMs, but nothing for the retry budget — so there is no way to raise it short of patching the package.

Why we are asking

The underlying queue counts deliveries rather than failures, so attempts are consumed by lost workers as well as by genuine errors (filed separately). On a platform where the process can be replaced mid-step, that makes the effective budget for real retries smaller than three, and raising it would be a reasonable stopgap that is not available to us.

Is the value deliberate? And is there a recommended approach for long-running steps on infrastructure where the process can be replaced while a step is in flight?

Related: #3992 (attempts are consumed by lost workers rather than failures) and #3993 (recovery only runs at startup).

Start with dist/queue.js:114 and trace how PostgresWorldConfig is defined and consumed. Check whether configuration tests or documentation cover queue options; done should establish a supported retry-budget setting, preserve existing behavior by default, and verify the resulting maxAttempts value.