[CI] Restart sidecar↔ambient demo pods so HTTP graph edges appear promptly

[jshaughn]

Closes #10249

Summary

The ambient Cypress job spent ~15–23 extra minutes in [Traffic] Sidecar Ambient traffic waiting for HTTP graph edges that never appeared on the original pods.

On a fresh Sail install, ambient→sidecar HTTP dest-reporter metrics are labeled source_workload=unknown for the life of those pods. Kiali correctly skips that series (IsBadSourceTelemetry case 1), so the graph stays at 2 HTTP / 6 total instead of 4 HTTP / 8. TCP on the same path is labeled curl-client immediately; sidecar→ambient HTTP is also fine. Restarting the demo deployments later, after the mesh is warm, opens new HBONE connections with curl-client labels and the existing graph wait succeeds in ~45s.

This PR:

• Restarts test-ambient / test-sidecar deployments immediately before the existing sidecar-ambient graph wait (that scenario already runs after other waypoint tests, so the mesh is warm).
• Names the echo Service ports http (appProtocol: http) and gives the demo curl loops connect/max timeouts so generators do not hang.
• Lowers the graph-wait maxRetries from 90 (15 min) to 30 (5 min). The pass condition is unchanged.

The Cypress scenario and its expectations are unchanged. waypoint.feature still asserts 8 edges (HTTP+TCP), then 4 (ambient off), then 4 (TCP off). The wait still requires ≥4 HTTP and ≥8 total edges.

Test plan

• Full Kiali CI on this PR (workflow restored to the normal job graph)
• Ambient job around the historical ~12–14 min, not ~39–42 min
• [Traffic] Sidecar Ambient traffic passes on attempt 1 in under a minute (no 15-minute poll, no Cypress retry)

[jshaughn]

How this resolves the hang (test unchanged)

The failing scenario is still [Traffic] Sidecar Ambient traffic in waypoint.feature. We did not change that feature file, its @tags, or its assertions (8 edges with HTTP+TCP, then 4 with ambient off, then 4 with TCP off). The wait still requires ≥4 HTTP and ≥8 total graph edges for test-ambient,test-sidecar. This is not a weakened test.

What actually failed was telemetry, not the UI:

1. Ambient→sidecar HTTP has no source-reporter L7 (ztunnel is L4). The only HTTP series is dest-reporter on the sidecar.
2. On a fresh Sail mesh, that dest-reporter series is request_protocol=http, 200, mTLS, SPIFFE set, but source_workload=unknown / source_app=unknown / source_cluster=unknown for the life of those pods. L4 TCP on the same hop is labeled curl-client. Sidecar→ambient HTTP (source reporter) is also curl-client.
3. Kiali IsBadSourceTelemetry case 1 drops namespace-OK / workload-and-app-unknown series. The graph therefore stays at 2 HTTP / 6 total (HTTP missing on the two ambient→sidecar hops; TCP still draws the nodes). Waiting 15 minutes on the same generation does not rewrite the labels.
4. The same topology on a warm mesh (or after a rollout restart of those four deployments) emits source_workload=curl-client, and the existing wait sees 4 HTTP / 8 immediately.

The Cypress step the graph page has enough data for sidecar ambient traffic now kubectl rollout restarts the demo deployments in test-sidecar and test-ambient, waits for rollout, then runs the same graph wait as before. That step already runs after the other waypoint scenarios, so the mesh is warm. Measured on this PR: the scenario passed on attempt 1 in ~45–50s; the ambient job dropped from ~39–42 min to ~14 min.

Demo-only extras (not test expectations): echo Service name: http / appProtocol: http, and curl --connect-timeout / --max-time so hung clients cannot stall the generator. Graph-wait maxRetries 90→30 only bounds how long we poll; it does not change what counts as enough data.

[jmazzitelli]

tests are green. ambient tests finished in 11m and 16m which seems like it was much faster.