uv/host: Strip stdout of sw_vers on MacOS

[zsol]

The output of sw_vers on various MacOS versions (in my case 26.1) can include a newline at the end, which causes:

ERROR: /private/var/tmp/_bazel_zsol/63b99ba49019d270ca10253bff172211/external/aspect_rules_py+/uv/private/constraints/platform/BUILD.bazel:81:9: in _platform_version_at_least rule @@aspect_rules_py+//uv/private/constraints/platform:_is_macos_at_least_10_13_flag:
Traceback (most recent call last):
	File "/private/var/tmp/_bazel_zsol/63b99ba49019d270ca10253bff172211/external/aspect_rules_py+/uv/private/constraints/platform/defs.bzl", line 62, column 12, in _platform_version_at_least_impl
		int(x)
Error in int: invalid base-10 literal: "1\n"

This PR avoids the error by calling strip() on the result of sw_vers -productVersion.

---

Changes are visible to end-users: yes

• Searched for relevant documentation and updated as needed: yes
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: yes

Fixed an issue with using the experimental uv rules on MacOS 26.1

Test plan

• Covered by existing test cases

[CLAassistant]

All committers have signed the CLA.

[arrdem]

Ah thanks this is something @dzbarsky and I ran into and I thought we'd fixed already.

[aspect-workflows]

test-os:linux-bzl:8 (Test)

All tests were cache hits

38 tests (100.0%) were fully cached saving 48s.

---

test-os:linux-bzl:latest (Test)

All tests were cache hits

38 tests (100.0%) were fully cached saving 48s.

---

test-os:linux-bzl:8 (Test)

e2e

All tests were cache hits

14 tests (100.0%) were fully cached saving 10s.

---

test-os:linux-bzl:latest (Test)

e2e

All tests were cache hits

14 tests (100.0%) were fully cached saving 10s.

---

test-os:linux-bzl:8 (Test)

examples/uv_pip_compile

All tests were cache hits

1 test (100.0%) was fully cached saving 335ms.

---

test-os:linux-bzl:latest (Test)

examples/uv_pip_compile

All tests were cache hits

1 test (100.0%) was fully cached saving 335ms.

[dzbarsky]

Ah thanks this is something @dzbarsky and I ran into and I thought we'd fixed already.

My bad the fix was on my local branch with other changes and never made it to remote