updated best icon selection logic

ARCHITECTURE.md

@@ -273,19 +273,22 @@ WHERE url_path = '/'
 
 **Selection priority (decision flow):**
 
-1. Standard square sizes (32x32, 64x64, 48x48, 16x16) — ideal for tab display. Prefer larger.
-2. Other square sizes ≤64px — close enough. Prefer larger.
-3. Non-square but both dimensions ≤64px — acceptable. Prefer larger.
-4. Everything else (180x180, 192x192, SVG with no dimensions, etc.) — last resort, will be downscaled in bundle generation.
+Target: 32x32 source icon. The frontend displays favicons at 16x16 CSS pixels, which is 32x32 physical pixels on 2x Retina screens. So 32x32 is the ideal source resolution — crisp on Retina without wasting bundle space.
 
-Within the same tier: prefer PNG/GIF/ICO over WebP over SVG, then smaller file size as tiebreaker.
+1. **Icons ≥32px** (preferred): smallest first, so closest to 32 wins. A 32x32 beats a 48x48 beats a 180x180.
+2. **Icons <32px** (fallback): largest first. A 16x16 beats an 8x8.
+3. **Unknown dimensions** (NULL width/height): last resort.
+
+Within the same size tier:
+- Prefer PNG > ICO > GIF/JPEG/BMP > WebP
+- Tiebreaker: smaller file size
+
+SVGs excluded (can't rasterize without external deps). Icons ≤2x2 excluded (tracking pixels).
 
 Does not distinguish between `favicon_ico` and `link_rel` sources — purely based on what was actually downloaded and its dimensions/format.
 
 Uses `DISTINCT ON (host_id)` for efficient single-pass selection. See `pipeline/04_best_icon/select.sql`.
 
-**Note on SVG/WebP:** Lower priority because rasterizing SVG adds complexity and WebP-to-PNG re-encoding may increase size. Only selected when no raster alternatives exist.
-
 **Stats emitted:** Hosts with icons selected, hosts without any icon.
 
 ### Stage 5: Bundle Generation