feat(gui): migrate 22 of 27 clientImages() status icons to CamuleArtProvider (#675) - #747

…rovider (amule-org#675)

Continues the icon-system cleanup scoped in amule-org#675. clientImages() is
the last of the raw-bitmap banks, and the riskiest: it's consumed
through a wxImageList built once at startup (Apply_Clients_Skin,
amuleDlg.cpp) by iterating index 0..26 in ClientSkinEnum order, and
four call sites then index that list with arithmetic
(Client_InvalidRating_Smiley + rating - 1) rather than calling
clientImages() directly. The enum order is load-bearing; this PR does
not touch it, the calling loop, or the arithmetic call sites -- only
what clientImages(index) returns for each index.

22 of the 27 icons are generic pictograms (smileys, a checkmark, an
X, stars, an arrow, a key, ...) with no external branding, migrated to
new "amule:client_<name>" SVG/PNG art. The remaining 5 -- indices 12,
15, 16, 17, 18 (eMule/aMule/lphant/Shareaza/xMule) -- are specific
client-software mascots and are deliberately left as the original raw
artwork: a generated pictogram is one thing, but redrawing someone
else's brand mascot risks not matching the real logo, which is worse
than not touching it. amule-org#675 discussion flagged this distinction
explicitly.

New art, per icon:
- Green/Red/Yellow/Grey/White: the 5 base transfer-state smileys.
- ExtendedProtocol/SecIdent/BadGuy/Encryption: badge overlays drawn
  per GenericClientListCtrl.cpp's own comments ("the '-'", "the 'v'",
  "the 'X'", "the '\xc2\xbf' except it's a key").
- CreditsGrey/CreditsYellow: the two credit-system stars.
- Upload: the upload-active arrow.
- Friend: the friend-list badge.
- mlDonkey/eDonkeyHybrid: kept generic/abstract (a checkmark badge, a
  simple ghost) rather than attempting their real logos -- same
  reasoning as the 5 mascots, lower bar since these were already more
  abstract marks than full character art in the original raster.
- Unknown: the unresolved-client-type question mark.
- InvalidRating/PoorRating/FairRating/GoodRating/ExcellentRating: one
  potion-bottle SVG re-tinted per rating (red/red/orange/green/green),
  with Invalid and Excellent composited as two bottles side by side in
  a single 16x16 square canvas -- matching the original art's
  single-vs-double-bottle distinction for the two rating extremes.
- CommentOnly: the comment-icon badge.

Implementation: a static art-id lookup table indexed by ClientSkinEnum
value, checked first; a null entry falls through to the corresponding
raw-bitmap `if (index == N)` block for the 5 mascot indices, which are
otherwise untouched. src/icons/icon_data.c regenerated via
embed_icons.py to match.

Testing: full build verified (macOS), both Release and Debug config.
Debug build launched with a live window (Apply_Clients_Skin runs at
startup, touching all 27 indices) and produced no wxFAIL_MSG assertion
(amule-org#739) -- confirms every index resolves. Each new icon reviewed
individually via rasterized contact sheets at both ~96px and actual
16x16 before being wired in.

NOT independently verified: seeing these icons rendered in an actual
populated client list (Downloads sources, Shared Files clients, Search
results, Friends) requires live eD2k/Kad network data, which a
from-scratch test config doesn't have. Same limitation already flagged
for fileDetails/clientDetails/CategoriesEditWindow in amule-org#744.

…tic_assert (amule-org#747 review)

got3nks, reviewing amule-org#747:

1. client_invalidrating.svg / client_excellentrating.svg didn't fill
   their 2048x2048 viewport like their poor/fair/good siblings (53%x73%
   fill for those vs. 83%x44% for these, with the left bottle clipped
   at x=-47). Recentred both bottle <g> transforms to
   translate(-110,452)/translate(940,452) with scale raised to 0.8
   (from 0.6), matching the visual weight of the single-bottle ratings
   next to them in the same column. Both files are otherwise identical
   apart from fill colour, so the one fix applies to both.

2. Nothing tied artIds[] to ClientSkinEnum, and wxFAIL_MSG (amule-org#739)
   compiles out in release builds -- so a future enum member could
   silently push a wxNullBitmap into the 16x16 image list instead of
   failing loudly anywhere. Added
   static_assert(WXSIZEOF(artIds) == CLIENT_SKIN_SIZE, ...), which
   catches it at compile time in every build config. Needed
   "amuleDlg.h" (CLIENT_SKIN_SIZE's home) added to muuli_wdr.cpp's
   includes -- checked first that amuleDlg.h doesn't include
   muuli_wdr.h back, no circular include.

Verified via a full amule build (macOS) -- the static_assert compiling
clean confirms artIds[] and ClientSkinEnum agree on 27 entries, and a
visual check that the two rating icons now match their siblings' size
and no longer clip.

…mule-org#747 review)

My previous fix (eedcac3) just moved the problem: applying got3nks's
suggested translate values verbatim together with the also-suggested
scale=0.8 pushed the right bottle past the viewBox edge (measured:
x range 13%-107%, i.e. clipped on the right instead of the left).
The two numbers were each individually reasonable but hadn't been
re-verified together -- exactly the mistake the last commit's message
claimed to have checked and hadn't.

Recomputed from the natural bounding box instead of iterating on
coordinates by eye: two bottles at scale 0.68 with a 40-unit gap, each
positioned so both are fully inside the 0-2048 viewBox with equal
margins. Verified numerically (not just visually) before committing:
both groups' bboxes land at x 12.9%-49.0% and 51.0%-87.1%, y
25.2%-74.8% -- fully in bounds, no clipping on either side.

Worth being upfront about the height: overall fill is 74%x50%, not
poor/fair/good's 53%x73%. That's not a leftover bug -- fitting two
full-height copies of the same bottle side by side in a square without
overlap is not geometrically possible; matching the single bottles'
73% height would require the pair to be over twice as wide as the
viewBox. 50% is the tradeoff of choosing "fits, no clipping, similar
per-bottle proportions" over an unreachable exact size match.

Verified via a full amule build (macOS) and the bounding-box
computation above, re-run against the actual committed SVG files
rather than the standalone drafts, to catch exactly the kind of
last-mile mismatch that slipped through last time.

…review)

got3nks: rather than treat the double-bottle pair as a special case
with its own (necessarily shorter) height, make all five ratings
share one consistent bottle height, maximizing what the double-bottle
pair allows without clipping and bringing poor/fair/good down to
match -- they sit in the same column, so consistency across the set
matters more than any one icon being as large as it could be alone.

Recomputed from the natural bottle bounding box: scale 0.909 is the
largest that fits two bottles side by side (24-unit gap) inside the
2048x2048 viewBox with no clipping. Applied that same scale to the
single-bottle ratings, centred. All five now render their bottle at
the same height.

Verified numerically against the actual committed files: all five
land at y 16.8%-83.2% (66.3% height) and are within the 0-100% x
range -- identical height across poor/fair/good/invalid/excellent,
zero clipping.

Verified via a full amule build (macOS).

…tion (amule-org#747 review)

got3nks measured across every opaque pixel: red and yellow gained
brightness/saturation moving to the new art, but green lost both,
landing dimmer (53% mean brightness) than red (64%) and yellow (72%)
-- inverting the original's balance, where green and red were level
at 57%/55%. Green carries the most meaning of the three (actively
transferring), so it being the dimmest state undersells it.

Replaced Material Green 500 (#4CAF50, 57% sat / 69% val) with
#22CC1A (87% sat / 80% val), inside the ~#1BD816-#2ECC1F range
got3nks suggested to restore the original's emphasis. Red and yellow
untouched, per the review ("read fine as they are").

Verified via a full amule build (macOS) and a visual check of the
icon at 96px.

…org#747 review)

got3nks caught a real functional regression I'd missed (a second,
earlier review comment I hadn't seen when I replied to the later one
about colour): 6 of these icons aren't standalone -- GenericClientListCtrl.cpp
draws them as overlays on top of the base client icon at the same
point.x/realY. The original raw art kept each in a corner so the base
icon stayed visible underneath; my replacements were designed as
standalone centered pictograms, so they covered the icon they were
meant to annotate (creditsyellow at 14x13 was larger than the 12x12
base smiley it sat on).

Recomputed each as a corner badge, scaled/positioned to roughly the
original's measured footprint and anchor (his measurements, converted
from 16x16 pixel terms to the 2048x2048 viewBox):
- extendedprotocol: top-right, ~8x4
- secident: bottom-left, ~7x6
- creditsgrey/creditsyellow: top-right, ~9x9
- encryption: top-left, ~6x8

badguy is the one exception, and deliberately so: the original struck
through the *entire* icon rather than badging a corner, which reads as
intentional (a bad-guy client's status is fully overridden, not just
annotated) -- kept that full-cover behaviour rather than shrinking it
to a corner mark.

Also added the null-bitmap guard he flagged: wxArtProvider::GetBitmap()
returning wxNullBitmap for an unresolvable id was returning straight
through the new early-return path, never reaching the wxFAIL_MSG that
amule-org#739 added for exactly this failure mode. Added a wxASSERT_MSG on the
early-return path so a future icon rename can't silently regress back
to the "fails into a blank icon" state amule-org#725/amule-org#739 fixed.

Verified via a full amule build (macOS) and a visual check of all 6
badges at both 96px and actual 16x16, confirmed each sits in its
corner without covering the centre of the base icon.