## What happened

The top-bar clock's popup calendar shows the wrong weekday for every date past the first DST transition of the currently displayed month. On September 14, 2026 (a real-world Monday), the popup outlines "14" under the **TUE** column instead of **MON**. Looking at the grid closely: the date "5" is rendered twice in the first week (under both SAT and SUN), and every date afterwards is shifted one column to the right of its correct weekday for the rest of the month.

## What was expected

Each date should sit under its correct real-world weekday, matching `date -d <that date> +%A`.

## Root cause (found by inspection)

`Model.js`'s `monthGrid()` (in `shell/plugins/panels/clock/Model.js`) builds the 6-week grid by walking a JS `Date` one day at a time at local midnight:

```js
var cursor = new Date(year, month, 1 - leading)
...
cursor.setDate(cursor.getDate() + 1)
```

This breaks when the walk crosses a timezone's "spring forward from local midnight" DST transition — i.e. when local midnight for a given calendar date does not exist. Chile (`America/Santiago`) does this on a systematic base:

```
$ TZ=America/Santiago zdump -v America/Santiago | grep 2026
America/Santiago  Sun Sep  6 03:59:59 2026 UT = Sat Sep  5 23:59:59 2026 -04 isdst=0 gmtoff=-14400
America/Santiago  Sun Sep  6 04:00:00 2026 UT = Sun Sep  6 01:00:00 2026 -03 isdst=1 gmtoff=-10800

$ date -d "2026-09-06 00:30"
date: invalid date ‘2026-09-06 00:30’
```

Because local midnight on Sept 6, 2026 doesn't exist in `America/Santiago`, constructing/advancing a `Date` to that instant gets normalized incorrectly, so `cursor` effectively fails to advance for that step. The grid then renders that day's date twice and every subsequent cell in the month is off by one column relative to its true weekday.

Likely fix: walk the grid using UTC-anchored dates (e.g. `Date.UTC(...)`, as `isoWeek()`/`dayOfYear()` in the same file already do) instead of local-midnight `Date` construction, so the walk can't land on a nonexistent local instant.

## Steps to reproduce

1. Set system timezone to `America/Santiago` (or any zone with a spring-forward-at-midnight transition in the displayed month — Chile's is the first Saturday→Sunday of September).
2. Open the top-bar clock's calendar popup for September 2026.
3. Observe: Sept 5 appears in both the SAT and SUN columns of the first week, and Sept 14 (a real Monday) is outlined under the TUE column.

## System details

- Omarchy version: 4.0.1-1
- Kernel: Linux 7.1.9-arch1-2 x86_64
- CPU/GPU: AMD Ryzen 9 270 w/ Radeon 780M Graphics
- Timezone: America/Santiago (-03/-04, Chile's 2026 DST rules)
- `omarchy debug` command was not found in this version (`omarchy commands --all` has no `debug` entry), so no diagnostic log/URL is attached.

## Screenshot

The popup showing Sept 14, 2026 outlined under TUE (and "5" duplicated under SAT/SUN in the row above) is attached below.

<img width="702" height="533" alt="Image" src="https://github.com/user-attachments/assets/92e7c79b-a38f-4d68-9cc2-e53b4edde384" />