ci: support for jobName flag and v3 messages

[migueldalberto]

Adds a --jobName argument to flow/util/uploadMetadata.py so the QoR metadata published to Pub/Sub can carry the canonical Jenkins pipeline name. When the argument is supplied, the message is emitted as schema v3 (the existing v2 structure plus a top-level job_name); when it is omitted, the script behaves exactly as before and emits v2.

This lets the palantir backend resolve the pipeline directly from job_name instead of classifying the raw BUILD_TAG with a hardcoded pattern table, so new pipelines appear on the dashboard without a backend code change.

What changed

• New --jobName argument (defaults to None).
• build_pipeline_payload sets payload_schema_version to 3 and adds job_name when --jobName is set; otherwise stays on 2. The backend requires a non-blank job_name for v3, so a blank value safely falls back to v2 and the legacy classifier.
• publish_pipeline_report sets the Pub/Sub `payload_schema_version`` message attribute to match the body (3 or 2).
• The >8 MB per-design fallback path is unchanged — it still emits v1 messages, which the backend continues to resolve via BUILD_TAG classification.

[gemini-code-assist]

Code Review

This pull request introduces a new --jobName command-line argument to uploadMetadata.py, enabling the emission of schema v3 payloads to Pub/Sub when a job name is provided. The review feedback suggests sanitizing the --jobName argument by stripping leading and trailing whitespaces. This ensures that empty or whitespace-only values do not incorrectly trigger schema v3, both when building the payload and when publishing the pipeline report.