feat(appearance): convert supported humanoids and wearable equipment

[zoeyrose]

Parent: atrinik/classic#224

Blocked by the proceed or explicitly bounded narrow decision in atrinik/classic#228.

Outcome

Expand the proven layered-frame appearance path across the supported humanoid and clothing-bearing model families and wearable/held equipment in reviewed, measurable content batches. Keep a generated coverage matrix and the current whole-face fallback until each exact family/pose/direction/slot/component combination is complete.

This repository owns authored visual layers, manifests, masks/palettes, identities, validation, provenance, and Classic-target packaging. Any newly discovered Classic renderer/protocol defect receives a focused linked issue in atrinik/classic; do not hide engine changes in content scripts or metadata.

Inventory and batching

Generate a complete inventory of:

• player, NPC, and humanoid/near-humanoid appearance families;
• clips/poses, directions, frame counts, dimensions, and existing aliases;
• possible visual slots and body-family compatibility;
• wearable and held item archetypes grouped into semantic visual components rather than one entry per statistically distinct clone;
• one-/two-handed, shield, robe/cape, hair/headgear, body-coverage, handedness, and direction-order conflicts;
• existing art that can be losslessly separated with approved provenance versus art requiring new human creation; and
• unsupported/non-applicable combinations and their named fallback.

Prioritize high-frequency player families and visually distinct equipment categories. Batch by one coherent family/slot group with bounded review size; do not create the Cartesian product of every item statistic and every body.

Authoring rules

• Reuse shared components only when their exact geometry, origin, anchors, pose/frame coverage, palette masks, source, and license are truly compatible.
• Use explicit authored palettes/masks. Inventory-icon color sampling remains prohibited.
• Preserve exact human/upstream authorship, transformations, license, attribution, and notice for every extracted or new layer. Generated visual art cannot ship as final content under #77.
• Every family may declare its own slots/capabilities. Clothing-bearing non-humanoids are allowed when authored; slotless models remain valid and need no empty humanoid layer set.
• Keep existing faces/animations usable until the generated report proves full support for the exact combination and the approved Classic target consumes it.

Acceptance criteria

• A deterministic generated matrix accounts for every inventoried appearance family, pose/direction/frame, visual slot, equipment component group, attribution/license state, and result: supported, legacy-fallback, not-applicable, or blocked with reason.
• Conversion proceeds in reviewed bounded batches whose golden composites cover base, each component, representative combinations, direction-dependent order, palettes, and exact fallback edges.
• Shared components do not silently misalign across bodies; family-specific geometry remains explicit where required.
• Player/NPC/monster appearance references and equipment archetype mappings resolve through stable catalog IDs and survive source moves covered by declared aliases.
• No unlicensed, unknown-provenance, generated-final, incomplete, oversized, or ambiguous member enters the Classic target.
• Clean/incremental and Linux/Windows builds remain deterministic, while existing unconverted runtime faces/animations remain usable.
• Each batch runs python3 tools/validate.py, an isolated Classic target build, deterministic golden composition checks, and git diff --check; linked Classic runtime batches also publish isolated local/remote screenshot and performance evidence.
• Closure requires zero unowned combinations in the declared support scope. Remaining fallbacks are explicit product decisions, not missing rows.

Non-goals

• Requiring all non-humanoids to wear clothing or use a humanoid skeleton.
• Procedurally inventing art for all equipment/body combinations.
• Removing the legacy fallback before coverage and runtime compatibility are complete.
• Implementing Classic renderer/protocol behavior in authored content.