Cover the eyes-open subquery with an index

The people filter was served from faces_image without touching a row;
reading the eye columns in the same subquery touched every one, and
ALTER TABLE had put those seven floats after the embedding and the crop
blob. One count took 24 seconds on the reference library, thirteen of
them system time. faces_eyes covers the subquery again: five
milliseconds.

docs/catalog.md

@@ -767,6 +767,11 @@ CREATE TABLE faces (
     detected_at INTEGER NOT NULL
 );
 CREATE INDEX faces_image ON faces(image_id);
+-- Covers the eyes-open filter's subquery. Without it every check read the
+-- whole face row -- the eye columns sit after the blobs -- and one count
+-- took 24 s on the reference library (schema V17).
+CREATE INDEX faces_eyes ON faces(image_id, eye_right, eye_right_px, eye_right_sharp,
+                                 eye_left, eye_left_px, eye_left_sharp, sunglasses);
 
 CREATE TABLE face_person (
     face_id     INTEGER PRIMARY KEY REFERENCES faces(id) ON DELETE CASCADE,

docs/faces.md

@@ -1403,6 +1403,12 @@ the honest answer is "everything". A test drives the same five readings through
 through `state()` and requires the two to agree, so the badge and the grid cannot say different
 things.
 
+**And an index, learned the slow way.** The people filter was always served from a covering index
+on `faces(image_id)`; the moment its subquery read the eye columns it had to read the face *row*,
+and `ALTER TABLE ADD COLUMN` had put those seven floats after the embedding and the crop blob —
+six kilobytes to reach every one. One count took 24 seconds on the reference library, thirteen of
+them system time. `faces_eyes` (schema V17) covers the subquery again: five milliseconds.
+
 ### 17.4 What the sample says about accuracy, and what it does not
 
 The 60-proxy sample above was run at proxy resolution, where the production pass reads the native