Async failed-queue hardening

Null-guards and post-deploy-verify additions on RFI / address-discovery paths reduce transient failures landing in the failed transport

Overview

A handful of transient failures in the messenger pipeline were ending up in the failed transport on preprod with NPE-shaped traces. The handlers that processed RFI events and address discovery results were assuming richer data shapes than the upstream paths always supplied. Release 3.10 hardens those handlers and adds verification hooks to catch a similar class of issue on every deploy.

What changed

Null-safety on RFI + address discovery

ProjectRequestForInformation and ProjectRequestForInformationLog got new defensive helpers; FoundAddressRepository and AddressDiscoveryService were updated to handle the missing-or-empty case explicitly rather than throwing on dereference.

A new AddressDiscoveryServiceTest (Unit) covers the previously-failing path so the regression is locked in.

Post-deploy verification additions

scripts/post-deploy-verify.ts got new checks that run after each release:prod / release:preprod symlink swap. Failures here surface immediately rather than on the next user request that touches the path.

scripts/release-prod-safe.ts similarly picked up extra guard logic during the build phase so the same class of issue cannot get cached into a release dir.

Why it matters

Messenger's failed transport is where transient errors go to die quietly. Without monitoring, items pile up there and get noticed only when someone wonders why an RFI didn't fire or an address didn't enrich. Adding null-safety + post-deploy verification reduces the volume that lands there in the first place and surfaces the surviving problems faster.

Verification

The new unit test covers the regression directly. Post-deploy verify ran clean on the v3.13.6 deploy.

Git tag v3.13.6.