docs: record how to find the messages item 41 affected

Confirmed on real mail: a message whose text/html part carries a
Content-Id now renders. Item 41's status drops the caveat about the
reported message not being relocated.

Finding an affected message is harder than it looks, which is why the
search is worth recording rather than rederiving. A Content-Id on an
inline image is the common case and always worked, so a plain grep for
the header returns mostly noise. The narrow case is a Content-Id in the
same header block as a text/html Content-Type, which needs a small awk
pass over the message files. That found 96 in one inbox, all bulk
senders.

Also records that file: is not a notmuch search term, so a matched path
cannot be turned into a query directly; the Message-ID header is the
way across to an id: query.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 21 insertions, 1 deletions

diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
index d4465ce..d98c91e 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
@@ -88,7 +88,7 @@ taking that too literally.
 | 38 | `test_mainwindow` fails when a real sync holds the lock | testing | XS | **done** |
 | 39 | Thread list cannot be sorted by clicking a column header | workflow | S | open |
 | 40 | No live filter over the current view | workflow | M | open |
-| 41 | A message whose HTML body carries a `Content-Id` renders blank | correctness | S | **done** (fixture-verified; the reported message was not relocated) |
+| 41 | A message whose HTML body carries a `Content-Id` renders blank | correctness | S | **done** |
 | 42 | "Syncing..." says nothing about what is being synced | feedback | S | open |
 | 43 | No "Mark all read" for the current view | workflow | S | open |
 | 44 | No way to manage the filters applied at sync time | workflow | ? | open, unspecified |
@@ -2062,6 +2062,26 @@ The two are independent, and the current code treats them as exclusive.
 item 15's namespacing is unaffected, which the existing mimeparser tests already
 cover.
 
+**Confirmed on real mail (2026-08-07).** Affected messages are not easy to find,
+because the common case, a `Content-Id` on an inline image, always worked and
+swamps a naive grep. The narrow case is a `Content-Id` in the *same header
+block* as a `Content-Type: text/html`:
+
+```bash
+notmuch search --output=files 'tag:inbox' | while read -r f; do
+  awk 'BEGIN { IGNORECASE=1; html=0; cid=0 }
+       /^$/   { if (html && cid) { print "yes"; exit }; html=0; cid=0; next }
+       /^Content-Type:[ \t]*text\/html/ { html=1; next }
+       /^Content-ID:/                   { cid=1;  next }
+       END    { if (html && cid) print "yes" }' "$f" | grep -q yes && printf '%s\n' "$f"
+done
+```
+
+That found 96 messages in one inbox, all from bulk senders, with 57 from a
+single one. Pull `Message-ID` from a match and paste it into the query bar as
+`id:<the-id>` to open it. Note `file:` is **not** a notmuch search term, so a
+path cannot be turned into a query directly; read the header instead.
+
 ## 42. "Syncing..." says nothing about what is being synced
 
 **Observed (user, 2026-08-05):** the only feedback during a manual sync is