fix(icons): inset the macOS app icon to Apple's 824/1024 safe area

macOS draws CFBundleIconFile into a fixed tile, so the artwork -- not the
canvas -- decides how large the app reads in the Dock. Apple's grid puts an
824x824 body in a 1024x1024 canvas, a 100px transparent margin on every side.
icon.icns shipped a full-bleed squircle (ratio 1.000 at every representation),
rendering ~1.24x wider than its neighbours: visibly "a size bigger" (#610).
Measured on macOS 26.6.2, Keynote/Pages/Maps/Chrome/Edge/OBS/Orca all sit at
824/1024, and a survey of 113 installed apps puts every slot >=32px in
0.802..0.807. codeg was the lone outlier.

icon.svg stays full-bleed on purpose -- the web favicon, the Windows .ico and
the Linux PNGs all want their canvas filled, and those PNGs are what
default_window_icon() hands the Windows and Linux tray -- so the inset is
applied only when building the .icns. macOS consumes nothing else: icon.icns
is the single icon asset that ends up inside codeg.app.

macos-icon.gen.py pads the SVG and hands it to `tauri icon` rather than
building an .iconset for `iconutil`. That choice is load-bearing: `tauri icon`
reproduces the chunk set this project has always shipped, keeping the legacy
il32/is32/l8mk/s8mk masks that carry the 16px and 32px slots for the
LSMinimumSystemVersion 10.13 floor we declare. `iconutil` instead writes
ic04/ic05 as raw ARGB and drops those masks. The generator reads icon.svg and
never its own output, so re-running it is a no-op.

The guard is the point: `tauri icon` regenerates full-bleed, and it gets run
for unrelated reasons -- 1d3dd0dc rewrote all 17 icon assets while fixing the
Windows ICO. A comment would not have stopped that, so macos_icon_geometry.rs
asserts the geometry on every PNG slot, pins the 1024 master to 824 +/-2 with a
100 +/-2 inset, and fails if ic04/ic05 ever appear. Verified it fails on the
old icon and passes on the new one.