feat: Add XPING_RUN_LABEL support for human-readable run identification

[xping-admin]

Problem

When Xping SDK runs locally (outside CI), the resulting session in the Dashboard has no human-readable identifier. It appears as an anonymous entry distinguishable only by machine name and timestamp, making it hard to find a specific run or correlate it with a developer's intent (e.g. "pre-PR smoke test for payment refactor").

CI runs benefit from rich context (commit SHA, branch, PR number, author) that is automatically captured. Local runs have none of this.

Proposed Solution

Add an optional RunLabel configuration property with a corresponding XPING_RUN_LABEL environment variable override.

Behaviour

• If XPING_RUN_LABEL is set in the environment, it takes precedence over the config value.
• The label is a free-form string (suggested max: 255 chars).
• It is attached to the uploaded session and displayed in the Dashboard as the primary display name for the run when CI context is absent.
• It is optional — existing behaviour is unchanged when not set.

Configuration

Via appsettings.json / SDK options:

{
  "Xping": {
    "RunLabel": "feat/payment-refund-fix – pre-PR smoke"
  }
}

Via environment variable:

export XPING_RUN_LABEL="feat/payment-refund-fix – pre-PR smoke"

Naming rationale

Follows the established SDK env var convention (XPING_ENVIRONMENT, XPING_STRICTMODE). XPING_RUN_LABEL is preferred over XPING_TAG (too generic) or XPING_EXECUTION_CORRELATION_KEY (too long, implies deduplication which is already handled by SessionCorrelationKey).

Industry References

• Datadog Test Visibility uses DD_TAGS with reserved env:/service:/version: keys for the same purpose.
• Sentry uses SENTRY_RELEASE as a human-readable version/label attached to all events in a session.
• ReportPortal uses a Launch name field for the same concept.

Acceptance Criteria

• XpingConfiguration has a nullable RunLabel string property
• XPING_RUN_LABEL env var is read and takes precedence over config
• RunLabel is included in the upload payload sent to the Dashboard API
• Unit tests cover env var resolution and config fallback
• SDK documentation / README updated