Add withErrorHandling to build-only tool logic functions

[cameroncooke]

Context

buildDeviceLogic in build_device.ts, build_simLogic in build_sim.ts, and buildMacOSLogic in build_macos.ts are not wrapped in withErrorHandling. If startBuildPipeline or executeXcodeBuildCommand throw an unexpected error (not a build failure, but e.g. a filesystem error), it would propagate unhandled.

The build_run_* variants do use withErrorHandling because they have additional post-build steps. The build-only tools rely on executeXcodeBuildCommand returning error information in buildResult.isError rather than throwing.

Flagged by Sentry bot on PR #325.

Recommendation

Add withErrorHandling wrappers to all three build-only logic functions for consistency and robustness against unexpected throws.

[cameroncooke]

Closing this after re-auditing the build-only and build-run xcodebuild paths.

executeXcodeBuildCommand is the shared execution boundary for build, test, and build-run tools. It already catches errors thrown by the injected CommandExecutor and converts them into { isError: true } responses. That behavior is covered in src/utils/__tests__/build-utils.test.ts for thrown spawn errors such as ENOENT, EACCES, and EPERM.

Because of that shared contract, the build-only tools should not add their own per-tool try/catch wrappers around executeXcodeBuildCommand. Doing so would duplicate the helper's error boundary and diverge from the existing build_run_* pattern.

The PR raised for this issue tested an artificial path by mocking executeXcodeBuildCommand itself to reject. That bypassed the real production seam (CommandExecutor) and produced a false positive: a normally non-throwing helper was made to look like it required caller-level catches.

If a concrete escaping path is found later, the fix should be made and tested at executeXcodeBuildCommand, not separately in each build-only tool.