docs/re: neither existing Canary hook can capture the title screen's draw order

The paint-order item's remaining step is a per-draw capture, and the obvious
move is to reuse the RE instrumentation already compiled into the Canary build
on `sylpheed-re`. Read the source rather than assume: neither hook works here.

`--log_draws` de-dups by vertex-declaration fingerprint, so a screen's sprites
collapse to one record; it carries no texture identity and only first-seen
order. The F10 ship capture does keep submission order and would separate the
elements, but it returns early on any draw without an `f32x3` position stream —
the comment says "UI/effects — skip" in as many words.

So the item needs a new cvar-gated hook and a `build-canary` run. Stated in the
entry so the cost is known before someone starts, and so this reading is not
repeated.

docs/re/BACKLOG.md

@@ -99,6 +99,29 @@ now either identical to the declaration table or refuted by the capture. The nex
 step is no longer static — it is either the guest code that walks this table, or a
 per-draw capture of the title screen showing the order the game submits.
 
+**Blocker, checked rather than assumed.** The obvious move is to reuse Canary's
+existing RE instrumentation, which is already in the built binary on
+`sylpheed-re`. Neither hook can answer this:
+
+- **`--log_draws`** (`command_processor.cc`) de-dups by a *vertex-declaration
+  fingerprint* — shader hash + primitive type + per-stream element
+  formats/offsets + index-buffer guest base — and writes each distinct one once.
+  A screen's sprites share a declaration, so they collapse; and the record
+  carries no texture identity and no per-frame submission order, only first-seen
+  order. It is a mesh-format log, not a draw-order log.
+- **The F10 ship capture** does preserve per-draw order within a frame and
+  de-dups on `(vertex base, WVP transform, index range)`, which would separate
+  the elements — but it **explicitly drops UI draws**:
+  `if (pos_off_bytes < 0 …) return;  // no float-position stream (UI/effects) —
+  skip`. It requires an `f32x3` position attribute, which a 2D quad stream does
+  not have.
+
+So this needs a **new hook in Canary** — log each draw in submission order with
+its bound texture fetch (or its screen-space quad), gated behind a cvar the way
+the other two are — and therefore a `build-canary` run. That is the cost to
+state up front rather than discover halfway in; it is not a container
+limitation, just a long build plus a title-screen run.
+
 
 ## Capital ships assemble wrong in the viewer