Add Cupertino Light theme to community themes

[jonnyace]

Adds the Cupertino Light community theme to the extra themes page.

• Preview: assets/themes/cupertino-light.webp (1200px wide)
• Entry added to themes/index.html in alphabetical order

Cupertino Light is a macOS-inspired light theme: system-blue accent, frosted shell surfaces, Sequoia-matching 10px window rounding, and Yaru-blue icons.

Install:

omarchy theme install https://github.com/jonnyace/omarchy-cupertino-light-theme.git

Dark sibling: #42

[omarchybot]

Reviewed.

Nothing blocking. The added block matches the neighbouring entries byte for byte (indentation, loading="lazy" decoding="async", alt="Cupertino Light theme", same URL in both links), src matches the file the commit adds, the preview is a real 1200x675 WebP at 26,048 bytes, and the entry sits correctly between Crimson Gold and Darcula. jonnyace/omarchy-cupertino-light-theme is public and lays out a real Omarchy theme at its root — colors.toml with mode = "light", backgrounds/, hyprland.lua, the shell.*.toml set — so pasting the URL into Install > Style > Theme resolves to slug cupertino-light and works.

One small thing: the preview image still shows the old name. The heading reads "Cupertino" and the terminal line is omarchy dev theme-preview cupertino, while the installed theme is now cupertino-light. Same in #42. Not worth a rebase on its own.

Merge order, for whoever lands these: this and #42 both insert between Crimson Gold and Darcula, so whichever goes second conflicts in themes/index.html and needs a rebase. Correctly sorted, Cupertino Dark comes before Cupertino Light. I merged all seven open theme PRs (#41–#47) onto master locally: that is the only conflict in the set — #43, #44, #45, #46 and #47 all merge cleanly in any order.

Tests: none run, and there are none to run — omarchy-site has no test suite or link checker, and its only workflows are GitHub's own Copilot reviewer, CodeQL and Pages deploy. Instead I parsed the merged page: tags balance, all 129 figure blocks match the canonical shape, and every img src on the page resolves to a file that exists in assets/themes/.

Second opinion from codex at xhigh: it reached the same conclusion and contributed the stale preview naming above, which I had not spotted. Its independence is not currently guaranteed. I rejected one of its findings — that the WebP was encoded at quality 92 rather than the documented 80 — because identify -format %Q reports 92 for all 124 previews already on master, so it is not reading back an encoder setting.

Waiting on the maintainer. Not merged and not approved; that call is theirs.