Make BazelBuildSystem error message complete on opaque exits

[obj-p]

Summary

CI run 25243519727 surfaced a snapshotBazel failure where bazel exited 7 with both stderr and stdout empty. The pre-existing error formatter in runBazel:

stderr: output.stderr.isEmpty ? output.stdout : output.stderr,

discarded one stream by design and yielded an empty diagnostic when both were empty. The test failure looked like:

Project build failed (exit code 7):

— with nothing after the colon, leaving no way to tell whether the failure was a corrupt bazel binary, a concurrent workspace lock, an analysis failure with output redirected, or something else.

The rerun of the same SHA passed, so this particular instance was transient. But silent-flake conditions in Bazel (server crashes, remote-cache evictions mid-fetch, partial bazelisk downloads, fd exhaustion) are common enough that we'll see it again. When we do, the test failure should point at the offending command, not at the absence of one.

Change

The thrown BuildSystemError.buildFailed now carries:

• the bazel command and arguments that failed
• the working directory (projectRoot)
• the captured stderr (or (empty) if truly silent)
• the captured stdout (or (empty) if truly silent)

No behavior change on the happy path. No public-API change to BuildSystemError.buildFailed — the diagnostic is composed into the existing stderr: field.

Why not also try to fix the underlying flake?

Without an actual reproduction we'd be speculating (version mismatch? concurrent jobs? remote cache state?). The diagnostic improvement is the load-bearing fix: the next occurrence will be self-describing instead of opaque, and we can address the actual root cause then. Adding speculative defensive layers (retry-on-fail, isolated --output_user_root) without evidence risks masking legitimate build failures.

Test plan

• swift build clean
• swift test --filter SnapshotCommandTests/snapshotBazel passes (4.8s) — happy path unaffected
• CI green