## Summary

`SnapBackend::checkForUpdates()` never signals completion of its update check when there are zero upgradeable snaps — which is the common, everyday case. This leaves Discover's Updates page permanently stuck on "Fetching updates" for any user with the Snap backend enabled, independent of bug 521682 (see "See Also" — that bug's regression is on `master`'s `EmitWhenChanged` refactor and doesn't exist in the 6.7.x stable branch; this is a different, older mechanism that predates that refactor).

## Root cause

`libdiscover/backends/SnapBackend/SnapBackend.cpp`, `checkForUpdates()`:

```cpp
void SnapBackend::checkForUpdates()
{
    if (m_updatesFetcher) {
        qWarning() << "Already fetching updates";
        return;
    }

    m_updatesFetcher = new StoredResultsStream({populate(m_client.findRefreshable())});
    connect(m_updatesFetcher, &StoredResultsStream::finishedResources, this, [this](const QVector<StreamResult> &resources) {
        for (SnapResource *res : std::as_const(m_resources)) {
            bool contained = kContains(resources, [res](const StreamResult &in) {
                return in.resource == res;
            });
            if (contained) {
                res->setState(AbstractResource::Upgradeable);
                res->updateSizes();
            }
        }
    });
}
```

If `resources` (from `m_client.findRefreshable()`) is empty, the loop never calls `res->setState(AbstractResource::Upgradeable)` for anything. That state-change call is the *only* thing that would trigger `StandardBackendUpdater::resourcesChanged()`, which starts the timer that eventually calls `refreshUpdateable()`. `SnapBackend` also never emits `contentsChanged`/`invalidated` on its own after this callback.

Since `refreshUpdateable()` is the only place that calls `setSettingUp(false)`, and `setSettingUp(false)` is the only place `m_hasBeenPopulated` gets set `true`, when there are zero upgradeable snaps `refreshUpdateable()` for the Snap updater is **never called even once**. `m_hasBeenPopulated` stays `false` for the life of the process, so `isFetchingUpdates()` (`fetchingUpdatesProgress() != 100 || m_settingUp || !m_hasBeenPopulated`) is permanently `true`, and since `ResourcesUpdatesModel::isFetching()` is `true` if *any* backend updater reports fetching, the whole Updates page hangs forever — even though every other backend (PackageKit, Flatpak, KNS, fwupd) completes normally.

Confirmed via a live diagnostic build (`ResourcesUpdatesModel::refreshFetching()` instrumented to log every updater's state every 3s): every other backend transitions to `isFetchingUpdates=false` within seconds; `SnapBackend` alone stays `true` indefinitely, with `isProgressing=false` and `fetchingUpdatesProgress=100` — the exact signature of `!m_hasBeenPopulated` never clearing.

`snap refresh --list` on the affected machine reports "All snaps up to date" — i.e. this reproduces precisely because there's nothing to update, which is presumably the *normal* steady state for most installations.

## Fix

```diff
--- a/libdiscover/backends/SnapBackend/SnapBackend.cpp
+++ b/libdiscover/backends/SnapBackend/SnapBackend.cpp
@@ checkForUpdates()
             if (contained) {
                 res->setState(AbstractResource::Upgradeable);
                 res->updateSizes();
             }
         }
+        // If nothing is upgradeable, no resource's state changes, so nothing
+        // downstream ever notices this check completed: StandardBackendUpdater
+        // only reacts to a resource transitioning to/from Upgradeable, or to
+        // contentsChanged/invalidated. Without an explicit signal here,
+        // refreshUpdateable() is never called even once when there are no
+        // pending snap updates, so m_hasBeenPopulated never becomes true and
+        // Discover's Updates page is stuck on "Fetching updates" forever.
+        Q_EMIT contentsChanged();
     });
 }
```

Also added a defensive 15s timeout around the `QSnapdRequest::runSync()` call in `populateJobsWithFilter()` (unrelated to the above, but `m_threadPool` has only one thread, so if `runSync()` ever genuinely hangs — observed but not fully root-caused — it would permanently block every subsequent snap search too; the timeout gives up and lets the rest of Discover proceed rather than wedging forever).

## Verification

Built locally as a patched RPM (Fedora 44, `plasma-discover-6.7.4-9.fc44.local`) and confirmed live: unpatched build stuck indefinitely on "Fetching updates" with zero snap updates pending; patched build correctly clears and shows "Up to date" within seconds.

## See Also

Bug 521682 — a different bug with an overlapping symptom (both leave Discover stuck on "Fetching updates"), but a distinct mechanism specific to an unreleased `master` refactor. Given how many duplicate reports of 521682 mention Snap specifically, it's plausible some of those reporters are actually hitting *this* bug rather than 521682's regression — worth checking whether their Snap backend also has zero pending updates.

Full diff and this write-up: happy to attach the patch here too if useful, same as I did on 521682.