fix: re-arm the remote-image block on every message load

"Load Images" lifts the WebKit content filter for the current message,
and load_html reset the images_allowed flag for the next one — but never
put the filter back, since apply_filter_policy only ran at view creation
and on the toggle. So after one "Load Images" every later message loaded
its remote images while the button read "Load Images" again. The load
path now re-applies the policy, and the block branch clears before adding
so it is safe to run with the filter already installed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

 src/wpe/host.rs | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/wpe/host.rs b/src/wpe/host.rs
index cca8ec8..4a4f191 100644
--- a/src/wpe/host.rs
+++ b/src/wpe/host.rs
@@ -263,18 +263,22 @@ impl MailWebView {
             return;
         }
         unsafe {
-            if self.images_allowed {
-                webkit_user_content_manager_remove_all_filters(self.ucm);
-            } else {
+            // Cleared before re-adding either way: the block branch runs
+            // on every message load, filter already installed or not.
+            webkit_user_content_manager_remove_all_filters(self.ucm);
+            if !self.images_allowed {
                 webkit_user_content_manager_add_filter(self.ucm, self.filter);
             }
         }
     }
 
     /// Show a message. Always re-arms the remote-content block: allowing
-    /// images is a per-message decision, never a sticky one.
+    /// images is a per-message decision, never a sticky one. The filter
+    /// goes back on here too — resetting the flag alone left the block
+    /// lifted for every message after the first "Load Images".
     pub fn load_html(&mut self, html: &str) {
         self.images_allowed = false;
+        self.apply_filter_policy();
         // NUL bytes would truncate the CString; they carry no meaning in
         // HTML, so strip rather than fail.
         let owned;