fix(ci): stabilize tracecontext job

[MukundaKatta]

Why

The tracecontext CI job is reported to flake intermittently (#5104). The integration script starts a Flask example server and then waits a hard-coded sleep 1 before running the W3C tests. On slow runners Flask is not yet listening when the tests start, and pytest fails with connection errors against 127.0.0.1:5000 (per the failed run referenced in the issue: https://github.com/open-telemetry/opentelemetry-python/actions/runs/24451853608/job/71442431200).

The issue author suggested adding readiness logic; this PR does exactly that.

What

In scripts/tracecontext-integration-test.sh:

• Drop the racy sleep 1.
• Add a wait_for_server function that polls 127.0.0.1:5000 for up to 30s with a 0.5s interval.
• Bail out early (and surface a clear error) if the example server process exits before becoming ready.
• Use Python (already required by the script) for the socket probe so we don't depend on nc/curl being installed on the runner image.
• Move the trap onshutdown EXIT registration before the readiness wait so that a failed readiness probe still cleans up the background server.

No behavior change in the happy path; the only observable difference is faster startup (typically <1s) and deterministic failure messages instead of cryptic connection errors.

Tested

• The diagnostic in the issue body links a CI run where the failure mode is exactly a connection error against the example server before it is bound to :5000. A port-readiness probe is the standard fix for this class of CI race.
• Reviewed the example server (tests/w3c_tracecontext_validation_server.py) to confirm it serves on the default Flask port 127.0.0.1:5000.
• Script remains POSIX /bin/sh compatible (no bashisms introduced).

Fixes #5104

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: MukundaKatta / name: Mukunda Rao Katta (df4ba43)

[MikeGoldsmith]

Looks good, thanks @MukundaKatta 🚀