ESD-1676: Fix NAT gateway diagnostics poll treating in-progress 400 as fatal

[Phil-Browne]

While a NAT gateway route-diagnostics operation is still processing, the API returns an HTTP 400 with {"message":"The polling result for async mode is not ready yet"}; completion is a 200 with a data array that may legitimately be empty. The poll treated that in-progress 400 as fatal and bailed on the first iteration, and treated an empty 200 as "still processing" (the reverse of the real contract), so anything slower than the 2s initial delay failed.

• Add an internal isNATGatewayDiagnosticsInProgress helper to detect the in-progress 400. It stays unexported on purpose: the signal is a message substring with no error code behind it, and other diagnostics endpoints report the same state differently, so it should not become public SDK surface.
• pollDiagnosticsRoutes now keeps polling on that signal, returns any other error unchanged, and treats a 200 as the completed result including an empty slice.
• Add poll-cadence override fields on the service (mirrors the MCR looking-glass poll) so the 400-then-200 transition is unit-tested deterministically without real sleeps.

Unit tests cover in-progress-then-complete, empty-complete, other-error-fatal, timeout, and caller-cancellation.

Contract verification

Verified against the megalith backend source (not just the SDK/spec):

• In-progress: DiagnosticsRoutesClient throws RoutesNotAvailableException("The polling result for async mode is not ready yet") on NetAuto status PENDING/RUNNING; the v3 NAT gateway controller re-throws it, and the global handler maps any unannotated RuntimeException to HTTP 400 with that string in the message field. So the 400 + message match is the real contract.
• Completion: COMPLETE status returns a 200, and an empty route list is a successful empty result, not "still processing".
• The signal is in message, not errorCode/data (no errorCode is set on this path).
• The equivalent v2 MCR endpoint reports the same state as an HTTP 202 instead, which is why this helper is scoped to NAT gateway rather than shared.

What I could not verify

• The in-progress message is a hardcoded string constant in the backend with no stable errorCode behind it, and it is not in the OpenAPI spec (the endpoint documents only a 200 and a catch-all 4XX). A future wording change would silently break the substring match; keying on a stable errorCode would be more robust if the backend ever exposes one.