kad: cap CKeyEntry::m_filenames so the list can't grow unbounded - #652

Bug investigation in #314.

@ngosang's 20-min heaptrack of amuled (after 6 h warm-up on a 7 TB shareset) showed leaks heavily concentrated in the Kademlia keyword-index code path:

289.57K leaked over 87497 calls from
  Kademlia::CEntry::sFileNameEntry(sFileNameEntry const&)
    at Entry.h:59
  std::__cxx11::list<sFileNameEntry>::push_front
  Kademlia::CEntry::SetFileName
    at Entry.cpp:118
  Kademlia::CKademliaUDPListener::Process2PublishKeyRequest
    at KademliaUDPListener.cpp:1036

Plus ~10 more entries in the top-30 leak list traced to the same handful of call sites in KademliaUDPListener.cpp and Indexed.cpp. Total leaked in 20 min: ~2.36 MB, which extrapolates to ~170 MB/day — consistent with the multi-day creep the issue originally reported.

Root cause

CKeyEntry::MergeIPsAndFilenames (src/kademlia/kademlia/Entry.cpp:350) merges the incoming entry's m_filenames list into the stored entry's, one sFileNameEntry per distinct publisher-chosen name. The publishing-IP list right next to it caps at 100 (:429-432); the filename list never got the matching cap. A popular file accumulates one entry per distinct filename variant — language renames, mirror prefixes, transliterations, case changes, trailing-paren copies — and the list grows monotonically for the lifetime of the entry.

GetCommonFileName already walks the list and returns the highest-m_popularityIndex entry as the displayed name, so the long-tail filename variants past a few dozen are read-only ballast.

Fix

Cap m_filenames at 100 entries (matching the m_publishingIPs cap), popularity-ordered: when the list grows past the cap, sort by m_popularityIndex descending and resize. GetCommonFileName's "most popular wins" semantics are preserved since the survivors are exactly the entries with the highest popularity counts.

What this doesn't change

CIndexed (the actual keyword → file index) is untouched. Search queries land there via keyword hash, not via per-file filename lists, and the KADEMLIAMAXINDEX = 60000 cap that protects it is unrelated. The filename list inside each CKeyEntry only ever feeds GetCommonFileName() for the displayed name in search-result rendering — capping it doesn't change which files appear or whether amuled answers a search, only which name shows next to a file when multiple publishers used multiple names.

eMule's reference code caps the equivalent list on the same shape; we just never ported that half when the 100-IP cap below was added.