fix(ui): use a template tray icon on macOS (#202)

Makes the macOS menu-bar icon a proper **template** image, so the OS
tints it
for light/dark/selected like every other menu-bar extra instead of it
sitting
there as the one coloured blob.

**Verified visually on macOS 26 hardware** (see Verification).

Scope note: this PR originally also carried a Dock-icon change. That
half was
**dropped** on review because it could not be demonstrated - the
findings are
preserved as documentation instead (DESIGN 8.1.1). See "Dock icon"
below.

## The config was a red herring

`tauri.conf.json` already had `trayIcon.iconAsTemplate: true`, but that
never
reaches the live icon: `tray.rs::build()` calls
`remove_tray_by_id("main")` and
replaces the config-defined tray with a runtime-generated
`"driven-main"` one,
built from `include_bytes!("icons/64x64.png")` (a white glyph on
**opaque
teal**) with `set_icon_as_template(false)` forced at four sites -
including one
inside the spinner animation task, which is the easy one to miss.

**Flipping that flag would have made it worse, not better.** macOS
template
images are alpha-only: AppKit discards the RGB and tints every pixel by
its
alpha. Handing it the opaque brand PNG renders a **solid black square**.

## What this does instead

- **New asset** `src-tauri/icons/tray-template.png` - 64x64, black on
transparency. Rasterised from the already-committed `icons/tray.svg`
(which
was always monochrome template art) with a throwaway supersampling
script; it
is just the union of that SVG's 4 circles, 1 rect and 1 polygon, so it
can be
  regenerated from the SVG with any rasteriser.
- **`TrayIcon::template_rgba_frame`** paints in *alpha*: the badge's
contrast
band is punched fully transparent (a template has no second ink, so a
hole is
the only way to separate the badge from the mark behind it), and each
state's
  glyph is cut **out** of the badge disc.
- The holes are cut with the **same glyph painters as the colour path**
-
rendered into a scratch buffer and inverted into alpha - so the
platforms
cannot drift apart in shape, and the spinner's comet-tail fade (and
therefore
  its frame-to-frame distinctness) survives.
- `set_template_mode()` replaces all four hardcoded `false` calls, so
the flag
can never disagree with the pixels just handed over. If the template PNG
ever
fails to decode it falls back to the colour path with template **off** -
never
  "opaque pixels declared as a template".
- Windows/Linux are unchanged.

## Deliberate divergence from DESIGN 8.1 - please sanity-check

**On macOS the tray state is now carried by SHAPE only; there is no
yellow or
red.** A template cannot express colour. This is sound because the badge
glyphs
(spinner / pause bars / `!` / `X`) were already designed to be readable
without
colour, and it is what `SPEC.md:1579`'s `iconAsTemplate` for macOS asks
for -
but it does contradict DESIGN 8.1's colour table, so `design/DESIGN.md`
now
carries an explicit macOS carve-out telling future readers not to revert
it.

The template badge is drawn larger than the colour one
(`BADGE_R_TEMPLATE` 0.28
vs `BADGE_R_COLOUR` 0.24, centre pulled in to 0.66) so the punched holes
survive
being scaled to a 22pt menu bar. An earlier attempt at 0.32 **overflowed
the
64px canvas and clipped flat against the edges** - caught by rendering
the
states and looking at them, and now guarded by a
`template_badge_fits_in_the_canvas` test.

## Dock icon: documented, not fixed (DESIGN 8.1.1)

`cargo tauri dev` shows the generic green "exec" icon. This is a
**dev-run
cosmetic artifact, not a shipped-product defect**, and after
investigation it is
deliberately not fixed in code:

- **Release bundles were never affected** - `icons/icon.icns` is in
`bundle.icon` and is a valid 1024px multi-rep icns, so `Driven.app` has
always
  had the right Dock icon.
- **Tauri already performs the only available runtime fix**: the icns is
genuinely embedded in the dev binary (verified by byte-searching it) and
`setApplicationIconImage` is already called at `RunEvent::Ready`.
Re-applying
  it is a re-run of a mechanism that is already executing.
- **That API cannot fix the surface most likely being seen anyway**:
status
bars / window switchers read `NSRunningApplication.icon()`, which
returns the
static **LaunchServices file-type** icon. Confirmed with a control
experiment -
a bundle-less process that successfully sets its own icon still reports
the
  generic one through that API.
- **The only real fix for an unbundled run is to run a bundled `.app`.**

All of the above is now written down in `DESIGN.md` 8.1.1 so nobody
re-derives
it. If the generic icon is ever reported against a *release* build, that
is a
different bug with different evidence.

## Verification

**Confirmed visually on hardware.** Built and ran the app, then captured
the
real menu bar: the Driven icon (cloud + up-chevron) renders in exactly
the same
single-colour tint and weight as its neighbouring template icons - the
reported
coloured blob is gone.

All five states were additionally rendered to PNG and inspected at
**22px and
44px** in simulated **light and dark** menu bars: idle / spinner /
pause-bars /
`!` / `X` stay mutually distinguishable by shape at menu-bar size.

## Gates

- `cargo clippy --workspace --all-targets -- -D warnings` - clean
- `cargo fmt --all -- --check` - clean
- `SQLX_OFFLINE=true cargo test --workspace` - green (37 suites, 0
failures)
- No `ui/` files touched, so the pnpm gates do not apply.
- Diff is 3 files: `tray.rs`, the new PNG, and `DESIGN.md`. No
dependency or
  lockfile changes.

New tests: seven macOS-gated tray tests asserting on the **alpha**
channel (the
only channel macOS reads), including `template_source_is_alpha_shaped`
as the
explicit guard against the solid-black-square regression.

Author: pmaxhogan

design/DESIGN.md

@@ -1398,6 +1398,59 @@ Always-present icon. States:
 | Red                   | Error state requires attention (auth needed, decrypt failure, disk full)    |
 
 The yellow-with-`!` state covers all of §5.8's network failure modes.
+
+**macOS carve-out - the colours above are Windows/Linux only.** macOS
+menu-bar extras are expected to be *template* images: alpha-only art the
+OS tints itself (black on a light menu bar, white on a dark or selected
+one). A colour-bearing icon there does not read as themed, it reads as
+broken - it is the one coloured blob among the system's monochrome
+extras. So on macOS the tray renders a template mark and **state is
+carried by the badge SHAPE alone**: spinner = syncing, pause bars =
+paused, `!` = network attention, `X` = error, plain mark = idle. That is
+the same shape vocabulary as the table above, minus the colour; the
+glyphs were always designed to be readable without colour (colour-blind
+users, tiny trays), which is what makes dropping it safe here. macOS
+therefore has no yellow or red tray icon - every other mention of a
+"yellow"/"red" tray icon in this document (§5.8.1, §5.10.2) means the
+shape-equivalent state there. This is deliberate and matches SPEC
+§1579's `iconAsTemplate` for macOS; do **not** "fix" the macOS path back
+to a colour icon.
+
+#### 8.1.1 macOS Dock icon on `cargo tauri dev` (known, dev-only, WONTFIX)
+
+**A `cargo tauri dev` run shows the generic green "exec" icon instead of
+the Driven mark. This is a dev-run cosmetic artifact, not a defect in the
+shipped product** - do not spend time "fixing" it in the app, and do not
+treat a report of it against a dev build as a release bug.
+
+Why: `cargo tauri dev` launches the bare `driven-app` Mach-O with no
+`.app` wrapper, so LaunchServices has no icon to associate with the
+process. A packaged build is unaffected - `icons/icon.icns` is listed in
+`bundle.icon` in `tauri.conf.json` and ends up in `Contents/Resources`,
+so `Driven.app` has always had the correct Dock icon.
+
+Investigated 2026-07 and deliberately NOT fixed in code. The findings,
+so nobody re-derives them:
+
+- **Tauri already does the only available runtime fix.** `tauri-codegen`
+  embeds the icns whenever `target == MacOS && dev` (confirmed: the icns
+  bytes are present verbatim in the built dev binary), and `tauri`
+  calls `-[NSApplication setApplicationIconImage:]` at `RunEvent::Ready`.
+  Re-applying it later is a re-run of a mechanism already executing.
+- **`setApplicationIconImage:` cannot fix the surface people usually
+  notice.** Third-party status bars, window switchers, and anything else
+  reading `NSRunningApplication.icon()` get the **static LaunchServices
+  file-type icon**, which that call does not affect. Confirmed with a
+  control experiment: a bundle-less process that successfully sets its
+  own icon still reports the generic one through that API.
+- **So the only real fix for an unbundled run is to run a bundled
+  `.app`** (e.g. `cargo tauri build` and launch the bundle), not any
+  runtime API call.
+
+If the generic icon is ever reported against a RELEASE build, that is a
+different bug with different evidence (a broken/missing icns in the
+bundle) - chase it then, and do not assume it is this.
+
 The tooltip shows the specific condition ("Connected, no Internet",
 "Captive portal — click to sign in", "Google Drive is unavailable", etc.)
 and the tray menu surfaces the matching action ("Open captive portal",