docs: sharpen item 114 after a hand test on a loaded image

Not a regression and not something we removed: Save image is item 114,
still open. Item 127 removed Save LINK and deliberately left this one.

The circumstances the user reported sharpen it twice. The image had already
had its remote content loaded, so m_allowRemote was still true at the click.
That flag is live on the shared interceptor and cleared by the next
showThread(), so a download handler is subject to whatever it says at the
moment of the click rather than at render time. A naive handler therefore
looks perfect in exactly this case and fails once the grant is gone, which
makes "it worked when I tried it" worthless as evidence. The entry records
that both cases must be tested against a message whose grant has been
cleared.

The second is a corollary of item 127. downloadRequested is per-profile, so
connecting it lights up every download entry Chromium offers at once,
including the Save link just removed from the menu. An entry being absent
from a menu is not the same as the capability being absent, so the handler
must decide per request rather than merely exist.

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

1 files changed, 23 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 d7783f7..b4ca450 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
@@ -180,7 +180,7 @@ taking that too literally.
 | 108 | Acting on a thread root means the whole thread, though it displays one message | workflow | M | **done** 2026-08-16, unreleased. `messageScopeFor()` beside `scopeFor()`; five `*_thread` actions in a "Whole thread" submenu on `Ctrl+Alt+<key>`. User-visible: minor bump, `### Upgrading` written |
 | 112 | Toggle unread on a whole thread cannot reach "all unread" on a partly-read thread | defect | S | open, found 2026-08-17. A toggle over a UNION has no direction on a mixed thread |
 | 113 | No way to see a message's HTML source | information | S | open, 2026-08-17. Chromium's own View source cannot work here; needs our own plain-text dialog. Item 100 removed the dead entry, which was an overreach: the user had not asked for it |
-| 114 | Save image is offered on every image and does nothing | defect | S | open, found 2026-08-17 by right-clicking a real image. No `downloadRequested` handler exists anywhere, so the request is emitted and never answered |
+| 114 | Save image is offered on every image and does nothing | defect | S | open, found 2026-08-17, re-confirmed by hand 2026-08-20. No `downloadRequested` handler exists, so the request is emitted and never answered. The handler is per-profile, so it must decide per request or it revives the Save link item 127 removed |
 | 115 | A copy from the message pane gives no confirmation | presentation | XS | **done** 2026-08-19, unreleased. Four entries report, each naming what it copied; connected to the page's own QActions, so the entry is covered wherever it is triggered from |
 | 116 | Copy image copies markup instead of the image | defect | XS | **dropped** 2026-08-17, same day. NOT A DEFECT: `wl-paste --list-types` run immediately after a copy reports `image/png`, `application/x-qt-image` and 30 more image flavours. The clipboard is correct and Chromium is behaving. The earlier "text only" reading was taken minutes late off a clipboard that had been overwritten, and a whole cause was theorised on it |
 | 117 | The message pane offers no Select all | workflow | XS | **done** 2026-08-19, unreleased. `addPaneActions()` supplies it. The call site is NOT covered by a test and cannot be: the production menu needs a real context-menu event. Stated in the test rather than faked |
@@ -730,6 +730,28 @@ for the network to satisfy it.
 
 **Size: S.**
 
+**Re-confirmed by hand on 2026-08-20**, after items 126 and 127 shipped: the
+user right-clicked an image whose remote content had already been loaded and
+reported "Save Image but does nothing". Still this item, still unfixed, and the
+circumstances sharpen two things.
+
+`m_allowRemote` is a live flag on the shared interceptor
+(`src/requestinterceptor.h:56`), granted by `loadRemoteContent()` for the
+displayed message and cleared by the next `showThread()`. So a download handler
+would be subject to whatever the flag says AT THE MOMENT OF THE CLICK, not at
+render time. In the reported case the grant is still live, so a naive handler
+would appear to work perfectly, which is exactly the trap: the same code fails
+for a `cid:` image after the user moves on, and succeeds for a remote one only
+while the grant happens to stand. **Test both against a message whose grant has
+been cleared**, or the implementation is only tested in its easy state.
+
+The second is a corollary of item 127's decision below. The handler is
+per-PROFILE, so connecting `downloadRequested` lights up every download entry
+Chromium offers at once, including the Save link this pane deliberately removed.
+The entry being gone from the menu is not the same as the capability being
+absent: a page can still originate a download by other means. Whatever answers
+`downloadRequested` must decide per request, not merely exist.
+
 **Save LINK is no longer part of this item** (2026-08-20, item 127). It was
 deferred here on the grounds that both are inert for want of a
 `downloadRequested` handler, which is true and beside the point: they are not