feat(buildkite): pass through BuildMetadata

[JamyDev]

What?

Thread BuildMetadata through the Buildkite BuildRunner so callers can attach attributes (requester, ticket ID, trace ID) at trigger time and recover them from any subsequent Status call
— with no local state required.

• Trigger: JSON-encodes the caller-supplied metadata into a new SQ_METADATA env var on the Buildkite build request. Omitted when metadata is nil/empty, keeping the payload clean for
  callers that don't use it.
• Status: decodes SQ_METADATA from the env vars Buildkite echoes back on the build object, merges with "url", and returns the combined map. Decode errors are swallowed — a corrupt
  env var must not fail a status poll.
• client.go: adds Env map[string]string to buildResponse to capture the echoed env vars from the Buildkite GET response.

Why?

The BuildRunner interface documents that metadata "MAY be persisted or echoed back via Status" — but the original implementation discarded it with _. Buildkite's REST API echoes the
build's env map on every GET response, which means the metadata can round-trip through Buildkite itself rather than requiring a separate store or in-memory cache. This keeps the
implementation stateless and satisfies the interface contract at no extra infrastructure cost.

Tests

• TestTrigger_WithMetadata_SetsEnvVar — captures the outbound request body, verifies SQ_METADATA is present, and round-trips the JSON back into BuildMetadata to assert key equality.
• TestTrigger_NilMetadata_NoMetadataEnvVar — verifies nil metadata produces no SQ_METADATA key (i.e. the env map stays clean).
• TestStatus_EchosCallerMetadata — serves a build response with SQ_METADATA set; asserts all caller keys and "url" are present in the returned metadata.
• TestStatus_NoMetadata_ReturnsOnlyURL — build response without SQ_METADATA; asserts the returned map is exactly {"url": "..."}, confirming the no-metadata path is unaffected.