re: refute my own batching hypothesis -- blend state, not linkage

Last iteration I proposed that the two sweeps share one indices=8 draw
because ptloop01 links to ptloop02, and said testing it needed a
loading-screen capture I lack. Wrong twice: a linked pair was already in
every capture, ptbtn00 -> ptbtn00f.

Measured: ptbtn00f is drawn ALONE in 899 (f6b) and 1441 (f6) draws and
batched in ZERO, while the sweeps pair up in 1092 and 1744. Linkage does not
batch. The constraint is blend state -- ptbtn00f is additive and its linked
partner alpha-over, which cannot share a draw. The sweeps batch because both
are additive on one page.

Page+blend is necessary but not sufficient: 8154/alpha-over appears as two
separate draws in a single frame, 2108 such draws in f6b. This removes a
wrong cause rather than supplying a batching rule.

Extends read_draws.py to preserve draw grouping (draw index and quad count
per draw); check_labels.py still passes unchanged as a regression control.

Refutation attempt on the port's 0x3002/0x3003 menu-item reading: survives.
958 of 970 stems contain "btn"; the 12 exceptions are psselect_slot and
psselect_slot_blank, which are menu rows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

crates/sylpheed-formats/examples/kind3002_names.rs

@@ -0,0 +1,38 @@
+//! What do 0x3002/0x3003 elements actually look like disc-wide?
+//! The port's menu-item rule keys on this class; this asks whether the class is
+//! uniformly menu-row-shaped or whether it contains other things too.
+use sylpheed_formats::{pak::PakArchive, ui_layout};
+use std::collections::BTreeMap;
+use std::path::PathBuf;
+fn main() {
+    let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
+    let mut names: BTreeMap<String, usize> = BTreeMap::new();
+    let mut paks: Vec<_> = std::fs::read_dir(root.join("dat")).expect("dat")
+        .filter_map(|e| e.ok()).map(|e| e.path())
+        .filter(|p| p.extension().map(|x| x=="pak").unwrap_or(false)).collect();
+    paks.sort();
+    for p in &paks {
+        let Ok(ar)=PakArchive::open(p) else { continue };
+        for ent in ar.entries() {
+            let Ok(by)=ar.read(ent) else { continue };
+            let Some(b)=ui_layout::parse_build(&by) else { continue };
+            for el in &b.elements {
+                if el.kind==0x3002 || el.kind==0x3003 {
+                    let stem = el.name.split('.').next().unwrap_or("");
+                    let cls: String = stem.trim_end_matches(|c:char| c.is_ascii_digit()).to_string();
+                    *names.entry(cls).or_default()+=1;
+                }
+            }
+        }
+    }
+    let total: usize = names.values().sum();
+    println!("0x3002/0x3003 elements disc-wide: {total}, {} name-stems", names.len());
+    let mut v: Vec<_> = names.into_iter().collect();
+    v.sort_by_key(|(_,n)| std::cmp::Reverse(*n));
+    let btn: usize = v.iter().filter(|(k,_)| k.contains("btn")).map(|(_,n)| n).sum();
+    println!("stems containing \"btn\": {btn} of {total} ({:.1}%)", 100.0*btn as f64/total as f64);
+    println!("\ntop stems:");
+    for (k,n) in v.iter().take(14) { println!("  {n:5}  {k}"); }
+    println!("\nNON-btn stems (the ones a menu-item rule would also claim):");
+    for (k,n) in v.iter().filter(|(k,_)| !k.contains("btn")).take(12) { println!("  {n:5}  {k}"); }
+}