fix(sonar): harden tailnet path before SonarQube scan (roll out infra-portal#1179)

[sudheer-monta]

What

Ports the tailscale-hardening fix from infra-portal#1179 into the two shared reusable workflows so it rolls out to every Kotlin service at once (all consumers pin @main):

• pull-request-kotlin.yml — before Upload results to SonarQube
• sonar-cloud.yml — before Analyze with SonarQube

Adds a "Wait for SonarQube to be reachable over the tailnet" step: a curl probe that polls https://sonarqube.vpn.internal.monta.app/api/v2/analysis/version (the exact endpoint the scanner hits first) until it answers, then lets the scan proceed.

Why

tailscale up returns before the DERP/route path has actually settled (we can't do direct connections, so traffic relays via DERP). The scanner's first call hits a half-open path and fails fast — its default connect timeout is only 5s — surfacing as the cryptic:

Failed to query server version: Call to URL [.../api/v2/analysis/version] failed: null

This has been forcing several CI retries across service-ocpp, service-notifications, service-data-broker, service-alerts, etc. Polling the endpoint both waits out the race and warms the relay path, so the scan starts on a connection we know works.

Safety / composition

• Guarded with the same if: conditions as the scan step it precedes, plus continue-on-error: \${{ inputs.sonar-non-blocking }} — so it composes cleanly with the non-blocking behaviour from chore: make SonarQube + Tailscale non-blocking in Kotlin CI [CPONETOPS-1078] #320/chore: skip SonarQube scan when Tailscale bring-up fails [CPONETOPS-1078] #321 and doesn't affect the SonarCloud path when Tailscale is skipped.
• Probe exits early on first success (~seconds in the normal case); worst case ~3–4 min before it errors with a DERP/route-health hint.
• No change to the scan steps themselves.

Follow-ups (not in this PR)

• Optional: raise the Gradle sonar scanner connectTimeout/responseTimeout (infra-portal#1179 also did this, but there Sonar runs via sonarqube-scan-action; here it runs via the gradle-multi-module action, so it'd need to go through gradle args).
• Longer term (per Jonas): move Sonar to self-hosted runners on the same network as SonarQube to drop the VPN dependency entirely.

Picks up the rollout Jonas flagged in #request-sre / #github.

🤖 Generated with Claude Code