fix(ec): drop late ed2k server replies after EC client switches to Kad - #37

Summary

Symmetric counterpart to #36. That PR hard-stopped the prior Kad search when an EC client starts a new search, blocking late KademliaSearchKeyword(0xffffffff, ...) callbacks from contaminating the new bucket. The reverse direction — ed2k → Kad — was unfixed: late ed2k server replies (TCP Local from ProcessSearchAnswer, UDP Global from ProcessUDPSearchAnswer) keep arriving for seconds after the original request and continue calling AddToList with m_currentSearch = 0xffffffff. With the EC sentinel pinned across all EC search types, those late results land in the new Kad search's m_results[0xffffffff].

Fix

Gate the two ed2k result-arrival paths on m_searchType being an ed2k type. Drop the packet otherwise.

if (m_searchType != LocalSearch && m_searchType != GlobalSearch) {
    return;  // late ed2k reply after EC switched to Kad — drop
}

Mirrors PR #36's approach (cheap one-line gate, no protocol or state-machine refactor).

Why monolithic / native GUI is (essentially) unaffected

Native GUI parallel searches keep m_currentSearch at bottom-half IDs allocated by CSearchDlg::StartNewSearch. When a Kad tab is opened, m_searchType becomes KadSearch and this gate drops late ed2k replies that would otherwise misroute to the Kad tab's bucket — a pre-existing GUI bug nobody noticed because cross-protocol hits in a Kad tab read as Kad noise.

The "correct" long-term fix on the GUI side is per-search-object tracking for ed2k searches mirroring Kad's CSearch, so late results can route to the right tab. Out of scope here.

Test plan

• amuled / amule with EC enabled.
• amuleweb (or amulegui): ed2k Global search "foo" → wait for initial server reply → start Kad search "bar" → result list contains only Kad results from "bar", no late ed2k results from "foo".
• Reverse direction (Kad → ed2k) — already covered by fix(ec): stop prior Kad search when EC client starts any new search #36, sanity-check it still works.

Discovered while verifying #36 on the test VM. Was about to reply on #31 when the contamination appeared in the reverse direction.