fix(worker): bound Redis outage shutdown

[Joncallim]

Source Issue

Issue: #179

Summary

• Bound queue Redis commands with finite command, connection, resend, and reconnect behavior.
• Treat periodic renewal uncertainty as lost local authority at a monotonic safety deadline, including never-settling and late-success cases.
• Let healthy work drain during a validated shutdown window, then fence every active claim and disconnect all queue clients exactly once.
• Preserve the initial-renewal rule: no task lookup, attempt, business, or terminal work begins until Redis confirms ownership.

Safety contract

Redis remains authoritative. A timeout never claims that a queue mutation succeeded. Processing and claim state remain available for ordinary later recovery. The worker logs only fixed categories and safe identifiers.

Validation

• npm test -- --run __tests__/core-diagnostic-output-closure.test.ts — 29 passed
• dedicated Redis 7 proof on an empty nonzero database — 3 passed, with QUEUE_OCCURRENCE_REDIS_MULTIPLICITY_OK, QUEUE_OCCURRENCE_REDIS_RECOVERY_OK, and QUEUE_OCCURRENCE_REDIS_SHUTDOWN_OK
• npm run test:unit:zero-skip — 117 files / 1,737 passed; 16 service-gated cases skipped locally, with the touched Redis suite run separately as required
• changed-file ESLint — passed
• npx tsc --noEmit — passed
• npm run build — passed
• git diff --check — passed
• negative mutations proved failure for infinite retries, missing watchdog, deadline reset on transient failure, late-success revival, indefinite stop, missing forced disconnect, and missing terminal fence

Residual boundary

This child bounds Redis-only stalls and prevents later Forge mutation after the fence. An already-started non-cooperative external input/output call cannot be transactionally revoked; this remains the accepted parent residual. R3D malformed-processing quarantine is intentionally out of scope.