fix: re-probe the local Blossom cache when the toggle flips

Flipping either local-cache setting called probe.invalidate(), which only
clears the TTL timestamp — it never re-runs the probe. Nothing else does
either: isAvailable() is reached only from the one-shot startup warm and
from inside findServers().

That leaves the feature dormant when enabled mid-session. The feed image
path gates on `available.value` (AccountViewModel.useLocalBlossomBridge
and shouldBridgeBlossomCache), so while the probe reads false no request
ever routes through the resolver, and the resolver is the only thing that
would have refreshed the probe. The settings "detected" chip reads the
same flow, so it also stays stale.

Re-probe right after invalidating so enabling the toggle activates the
feature — and reports its true state — in the same session.

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

amethyst/src/main/java/com/vitorpamplona/amethyst/AppModules.kt

@@ -1230,6 +1230,14 @@ class AppModules(
                         blossomResolver.uriToUrlCache.evictAll()
                         blossomResolver.blossomHitCache.cache.evictAll()
                         localBlossomCacheProbe.invalidate()
+                        // Re-probe immediately so enabling the feature activates it
+                        // this session. Otherwise `available` only advances when a
+                        // `blossom:` URI is resolved, and the common feed-image path
+                        // never routes through the resolver until `available` is
+                        // already true — so a freshly-enabled toggle (or a cache that
+                        // came up after launch) would stay dormant and the settings
+                        // "detected" chip would read stale.
+                        localBlossomCacheProbe.isAvailable()
                     }
                 }
             }