### System details

AMD Ryzen 5 7520U, AMD Radeon 610M, 8 GiB,  Omarchy 4.0.1-1

### What's wrong?

### Environment
- Omarchy version: 4.0.1-1
- Connected via a mobile phone hotspot (relevant — see Root cause)

### Description
When no location is manually set, `omarchy weather location` is supposed 
to show your auto-detected city name. Instead it sometimes shows a single 
bare number (e.g. `37.751000`) with no city name and no second coordinate. 
The weather data itself (temperature, forecast, etc.) is unaffected — 
this only breaks the location label.

### Steps to reproduce
1. Connect via a network whose public IP doesn't cleanly resolve to a 
   city — a mobile carrier hotspot is a reliable way to trigger this, 
   since carrier NAT gateways commonly return coordinates with no 
   resolvable city name.
2. Do not set a manual location:
```bash
   omarchy weather location --clear
```
3. Run:
```bash
   omarchy weather location
```
4. Compare against the raw API call:
```bash
   curl -fsS --max-time 4 "https://wttr.in/?format=%l"
```
   On affected connections, this returns raw coordinates 
   (e.g. `37.751000,-97.822000`) instead of a resolved city name.

### Expected behavior
Either a resolved city name, or — when wttr.in can't resolve one — the 
full coordinate pair or a clear "location unavailable" message.

### Actual behavior
A truncated, meaningless fragment (e.g. `37.751000`) with no indication 
anything went wrong.

### Root cause
In `omarchy-weather-location`, the no-args branch does:

```bash
name=$(curl -fsS --max-time 4 "https://wttr.in/?format=%l" 2>/dev/null)
name=${name%%,*}
```

This assumes wttr.in always returns `City, Country`, so it strips 
everything after the first comma to keep just the city. But when wttr.in 
can't resolve a city — which is common on mobile carrier connections, 
since NAT gateway IPs often don't map to a specific city — it falls back 
to returning raw coordinates instead. The same comma-stripping logic then 
runs against that coordinate pair, silently discarding the longitude and 
leaving an orphaned latitude value. This will affect any user checking 
weather over a mobile hotspot, not just an edge case.

### Suggested fix
Before stripping at the comma, check whether `$name` matches the script's 
own `COORDS_PATTERN` regex (already defined earlier in this file for the 
`--set` validation). If it matches, either keep the full coordinate pair 
as-is or fall back to a "location unavailable" message, rather than 
truncating it as if it were a city name.