Fix Patch Manager search-handle leaks causing unbounded CPU growth

[kartun83]

Summary

Two related leaks in the Patch Manager's search-handle bookkeeping (pluginLib::patchDB::DB) that cause plugin host CPU usage to climb after loading multiple banks / switching many patches, and never recover:

• PatchManager::updateStateAsync() only called cancelSearch() on the "found a datasource match" path; the "no match found" early return skipped it, so the Search stayed in DB::m_searches forever. Since DB::updateSearches() rescans every entry in m_searches (including leaked ones) against every newly loaded patch on each subsequent bank load/patch change, leaked searches make every future load do strictly more work, with cost proportional to cumulative history rather than current state.
• DB::cancelSearch() always inserted the handle into m_cancelledSearches, but that set is only ever pruned inside executeSearch()'s per-datasource cancellation check, which never runs for a search that has already completed — the common case for essentially every Patch Manager UI interaction (tree/list rebuilds, filtering, patch selection). This is a genuine unbounded memory leak, distinct in character from the first (insert/find/erase only, never iterated, so not itself a CPU driver).

Both were found while investigating Bitwig host CPU climbing to 150-170% and never dropping back after loading several banks and switching patches in Osirus/OsTIrus.

Changes

• updateStateAsync(): dispatch cancelSearch(handle) on the empty-results path too, mirroring the already-correct success path.
• cancelSearch(): only track a handle in m_cancelledSearches if the search hasn't completed yet, since a completed search will never be looked at again.

Test plan

• Builds clean (jucePluginLib, jucePluginEditorLib targets, Xcode/macOS)
• Reproduced the original symptom (Osirus/OsTIrus CLAP in Bitwig: load several banks, switch many patches, CPU climbs and doesn't recover) and confirmed CPU stays flat after this fix