Add stack service VCS SHA refs as `<properties>` in jUnit XML test reports

## Context

Relates to https://github.com/elastic/integrations/issues/18803 ([comment](https://github.com/elastic/integrations/issues/18803#issuecomment-4416840208))

When running integration tests, identifying which exact build of each stack service
(Elastic Agent, Elasticsearch, Kibana, Fleet Server) was used during a test run is
critical for triaging failures — especially in daily CI jobs where SNAPSHOT images
are updated frequently.

This information is already available via `elastic-package stack status`, which
displays a `VCS REF` column populated from the `org.label-schema.vcs-ref` Docker
image label:

```
╭──────────────────┬────────────────┬───────────────────┬───────────────────┬────────────╮
│ SERVICE │ VERSION │ STATUS │ IMAGE BUILD DATE │ VCS REF │
├──────────────────┼────────────────┼───────────────────┼───────────────────┼────────────┤
│ elastic-agent │ 9.5.0-SNAPSHOT │ running (healthy) │ 2026-05-10T03:11Z │ eac42baa7d │
│ elasticsearch │ 9.5.0-SNAPSHOT │ running (healthy) │ 2026-05-08T16:38Z │ 78c313d002 │
│ fleet-server │ 9.5.0-SNAPSHOT │ running (healthy) │ 2026-05-10T03:11Z │ eac42baa7d │
│ kibana │ 9.5.0-SNAPSHOT │ running (healthy) │ 2026-05-10T11:27Z │ 1dfe3071d2 │
╰──────────────────┴────────────────┴───────────────────┴───────────────────┴────────────╯
```

However, this data is not included in the jUnit XML test reports generated by
`elastic-package test`, which means automated issue reports and CI summaries have no
programmatic access to it.

## Proposal

Embed the VCS SHA and image build date for each running stack service as ``
elements within the `` block of the generated xUnit XML report.

The jUnit XML `` element is a well-established extension point supported
across all major reference schemas (JUnit team's own
[jenkins-junit.xsd](https://github.com/junit-team/junit5/blob/main/platform-tests/src/test/resources/jenkins-junit.xsd),
[Apache Maven Surefire XSD](https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd),
and [Windyroad/Ant JUnit schema](https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsd)).

The resulting XML would look like:

```xml

...

```

## Implementation notes

- The VCS REF data is already fetched from the `org.label-schema.vcs-ref` Docker
container label (see `internal/docker/docker.go`, `ConfigLabels.VCSRef`) and
surfaces through `internal/stack/compose.go`'s `ServiceStatus`.
- The xUnit formatter lives in
`internal/testrunner/reporters/formats/xunit.go`. The `testSuite` struct
currently has no `` field.
- The formatter function signature (`ReportFormatFunc`) would need to accept stack
service metadata so it can be included in the XML output.
- Properties should only be added when the information is available (i.e., stack is
running locally via Docker Compose); the field should be omitted gracefully for
serverless or environment-based stacks where labels may not be present.

## Benefit

Automated daily-job issue reports and CI tooling can surface the exact service SHAs
directly from the XML artifact, without requiring a human to cross-reference the
Buildkite log output.

Start by reading internal/testrunner/reporters/formats/xunit.go and trace ReportFormatFunc callers to see how stack metadata can reach the formatter. Then inspect internal/docker/docker.go and internal/stack/compose.go for ServiceStatus and VCSRef. Done means local Compose reports include available service VCS refs and build dates as testsuite properties, while serverless or environment-based reports omit them cleanly.

Written by the indexing model from the issue text.