util: conda --refresh-pins exits 0 silently when no release qualifies for a pin #2025

Describe the bug
When --refresh-pins cannot move a pin, util/conda_vendor.py refresh_pins() leaves the pin as it is, prints no warning, and exits 0. This happens whenever no release has a wheel for every conda Python on the pinned platform, because newest_wheel returns None. So a refresh that should flag a pin as stuck reports success.

Reproduction

• This hid a real defect in ci: promote free-threaded 3.14t to supported, with the GIL off (#1958) #2024. With 3.14t in the supported tier, conda_pythons() required an osx-64 cp314t wheel that no release has. The pin stayed at 48.0.1 / 2026-12-01 with no message. Only test_conda_platform_pin_refresh_1851::RefreshCommandTests::test_a_moved_pin_is_written_with_its_new_date caught it.
• Reading refresh_pins(): it returns 0 after ::warning or ::notice lines. The sys.exit(1 if failures else 0) belongs to a different mode.

Expected behavior
A pin that is due for review but cannot move, because no release qualifies, should at least emit a ::warning naming the pin and the missing wheel, or fail the refresh.

System information

• commit: main 185b3176f

Additional context

• Found during the ci: promote free-threaded 3.14t to supported, with the GIL off (#1958) #2024 review (ci: categorise the tests into tiers and run each tier where it belongs #1958 phase 4).
• ci: promote free-threaded 3.14t to supported, with the GIL off (#1958) #2024 also edits util/conda_vendor.py, so this waits until ci: promote free-threaded 3.14t to supported, with the GIL off (#1958) #2024 lands.