Session 115 — Fix decoupage frames worm/robotright (PTR header standalone)

Probleme

Apres le fix session 114 (chemins HQN), worm et robotright avaient maintenant
les bonnes couleurs mais un decoupage des frames incorrect :

• {@code worm_f0.png} affichait un fragment du sprite (jambes/torse seulement)
• 19 frames produites au lieu d’une trentaine attendue
• Frames de ~500 bytes au lieu de ~1.2 KB comme guard (sprite complet)
• Aspect general : chaque frame = un bout decale d’un personnage humanoide

Cause racine : utilisation des frame descs d’alien2

Dans la boucle {@code extraAlienSprites}, l’appel etait :

int saved = conv.convertObject(0, wadData, ptrData, ...)

Le parametre {@code 0} = {@code objIdx} dans le LNK. Mais worm/robotright ne
sont PAS references dans {@code GLFT_ObjGfxNames_l}, donc on lisait les
frame descs (LX, LY, LW, LH) de l’objet 0 = alien2.

Resultat : on decoupait le sprite worm avec les coordonnees prevues pour
alien2 — d’ou les fragments incoherents.

Les autres sprites HQN (guard, priest, insect, triclaw, ashnarg) marchent
car ils sont dans le LNK et ont leurs propres frame descs. Worm et
robotright sont speciaux : leurs WAD existent dans {@code media/hqn} mais
le LNK ne les reference pas.

Fix

Nouvelle methode {@code WadConverter.convertObjectStandalone(…)} qui :

1. Lit le header du fichier PTR (8 derniers bytes) :
   word[-4] = $FFFF (marqueur)
word[-3] = NOFF (nombre de frames)
word[-2] = WOFF (largeur d'une frame en colonnes)
word[-1] = HOFF (hauteur d'une frame en lignes)

2. Construit pour chaque frame {@code f} un {@code FrameDesc} synthetique :
   lx = f * WOFF, ly = 0, lw = WOFF, lh = HOFF

3. Delegue a {@code renderFrameHqn} ou {@code renderFrame} selon le format.

La boucle {@code extraAlienSprites} appelle desormais cette methode au lieu
de {@code convertObject(0, …)}, ne touchant pas au LNK.

Validation attendue

Apres re-export par {@code ./gradlew convertWads} :

• Log : PTR header: NOFF=N WOFF=W HOFF=H pour worm et robotright
• {@code assets/Textures/objects/worm/worm_f0.png} : un sprite complet de
  worm (ou plutot d’alien-warrior d’apres l’image, le nom est trompeur)
• Nombre de frames = NOFF lu dans le header (probablement >= 20)
• Tailles de frames coherentes (~1-2 KB chacune comme guard/insect)

Limitations residuelles

Les 5 vues de rotation (top/bot/lft/rgt/cmp) restent dans des fichiers
separees ({@code worm.top}, {@code worm.bot}, etc.) qui ne sont pas
traites par {@code WadConverter}. Le fichier {@code worm.wad} traite ici
contient probablement la vue principale (face avant). Les autres vues
requiereront un parser dedie si on veut le rendu 3D fidele.