fix #426: extract solid-colour (NO_POS_UVS) faces; skip untextured subsets only on building shells and cells like retail

The Holtburg windmill axle (GfxObj 0x010010CE, 8 polygons, all
Stippling.NoPos + SurfaceType.Base1Solid) extracted to a 0-vertex mesh.
NoPos ("NO_POS_UVS", acclient.h:7380-7388) means "this side has no
texture coordinates" — true of every solid-colour polygon, since
nothing samples them — not "there is no positive face". Extraction read
it as the latter and dropped the polygon entirely, client-wide, for
every untextured polygon on every object.

Retail's D3DPolyRender::DrawMesh (@0x0059d4a0, named-retail decomp
~line 426048) draws an untextured subset on an ordinary object exactly
like a textured one; the only retail cases that skip an untextured
subset are a building shell (RenderDeviceD3D::DrawBuilding @0x0059f2a0
sets ObjBuildingOrBuildingPart=1) or an EnvCell interior
(RenderDeviceD3D::DrawEnvCell @0x0059f170, arg4=1). The #119
investigation's "retail's skipNoTexture never draws them either"
conclusion was itself wrong as a general rule.

- MeshExtractor.PrepareGfxObjMeshData / GfxObjMesh.Build: emit the
  positive side whenever PosSurface is a valid index, regardless of
  NoPos; the existing UV-index-0 fallback already produces zero
  texcoords for a NoPos polygon with no UVs on the wire.
- RetailUntexturedSurfacePolicy.IsUntextured(SurfaceType): the one
  place that answers "is this surface textured"
  ((type & (Base1Image|Base1ClipMap)) == 0), replacing the old
  `isSolid = NoPos || Base1Solid` (which also mis-classified a NEG-side
  batch by the POS-side's NoPos flag).
- RetailUntexturedSubsetPolicy.Draws(isBuildingShell, isUntextured):
  the shared draw-time gate wired into WbDrawDispatcher.ClassifyBatches,
  .PackedOracle.ClassifyPackedBatches, and
  .DirectionalShadows.AddDirectionalShadowBatches — one predicate so the
  three walks cannot drift (Campaign VM VM6 lesson).
- CellMesh.cs / MeshExtractor.PrepareCellStructMeshData deliberately
  KEEP their NoPos-gated skip for cell-wall geometry — retail's
  DrawEnvCell really does skip untextured subsets there; register row
  AP-234 documents the NoPos-vs-Surface.Type approximation.
- PakFormat.CurrentBakeToolVersion 4->5 (LauncherInstallRecordStore in
  lockstep): a pak baked by an older tool is missing every untextured
  face. No bake was run as part of this commit.

Also fixed: WorldBuilder's own upstream ObjectMeshManager.cs has the
identical NoPos bug (ObjectMeshManager.cs:959,984) — our port had
faithfully carried it over, and our own conformance test
(Build_NoPosFlag_OnlyEmitsNegSide) asserted the bug as correct WB
conformance. Renamed/reworded to Build_NoPosFlag_EmitsBothPosAndNegSide
with a citation for why retail decomp overrides WB here.

Issue119UpNullGfxObjDumpTests re-run against the installed DAT:
#119's own two objects (0x010002B4 9/9 polys, 0x010008A8 1/1 poly) now
gate DRAWS on every polygon instead of extracting to nothing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

src/AcDream.Content/MeshExtractor.cs

@@ -347,9 +347,20 @@ public sealed class MeshExtractor {
             if (poly.VertexIds.Count < 3) continue;
 
             // Handle Positive Surface
-            if (!poly.Stippling.HasFlag(StipplingType.NoPos)) {
-                AddSurfaceToBatch(poly, poly.PosSurface, false);
-            }
+            // #426 (2026-08-23, Holtburg windmill axle 0x010010CE): NoPos
+            // ("NO_POS_UVS", acclient.h:7386) means "this side has no texture
+            // coordinates" — that's true of every SOLID-COLOUR polygon, not
+            // "there is no positive face". Retail's D3DPolyRender::DrawMesh
+            // draws untextured (solid) subsets on ordinary objects same as
+            // textured ones (see RetailUntexturedSurfacePolicy); only a
+            // building shell or an EnvCell interior skips them, and that is
+            // a DRAW-time decision (RetailUntexturedSubsetPolicy, applied in
+            // WbDrawDispatcher), not an extraction-time one. So the positive
+            // side is always emitted when PosSurface is a valid index;
+            // AddSurfaceToBatch already falls back to UV index 0 / zero
+            // texcoords (via BuildPolygonIndices) when NoPos leaves no UVs to
+            // read.
+            AddSurfaceToBatch(poly, poly.PosSurface, false);
 
             // Handle Negative Surface
             // Some objects use Clockwise CullMode to indicate negative surface data is present
@@ -376,7 +387,13 @@ public sealed class MeshExtractor {
                 TextureFormat textureFormat;
                 UploadPixelFormat? uploadPixelFormat = null;
                 UploadPixelType? uploadPixelType = null;
-                bool isSolid = poly.Stippling.HasFlag(StipplingType.NoPos) || surface.Type.HasFlag(SurfaceType.Base1Solid);
+                // #426: "solid" (untextured) is a SURFACE fact, not a
+                // polygon-stippling fact — see RetailUntexturedSurfacePolicy.
+                // The old `NoPos ||` term conflated "this polygon's positive
+                // side has no UVs" with "this surface is untextured"; it also
+                // wrongly classified a NEG-side batch by the POS-side's NoPos
+                // flag, since this method is shared by both sides.
+                bool isSolid = RetailUntexturedSurfacePolicy.IsUntextured(surface.Type);
                 bool isClipMap = surface.Type.HasFlag(SurfaceType.Base1ClipMap);
                 uint paletteId = 0;
                 bool isDxt3or5 = false;
@@ -710,6 +727,20 @@ public sealed class MeshExtractor {
             // GL cull enum: 0 = pos, 1 = pos twice with reversed winding,
             // 2 = pos + neg surface. The DAT-side NoPos/NoNeg flags still
             // suppress hidden portal/cap faces before they reach our mesh.
+            //
+            // #426: unlike PrepareGfxObjMeshData (ordinary objects — fixed to
+            // emit every NoPos-flagged positive side, since NoPos means "no
+            // UVs", not "no face"), this NoPos gate is INTENTIONALLY kept.
+            // Cell-wall geometry draws through retail's
+            // RenderDeviceD3D::DrawEnvCell (@0x0059f170), which calls
+            // D3DPolyRender::DrawMesh with arg4=1 and skips every UNTEXTURED
+            // subset — approximated here by the polygon's own NoPos flag
+            // rather than by resolving Surface.Type
+            // (Base1Image/Base1ClipMap, see RetailUntexturedSurfacePolicy)
+            // before this decision is made. See
+            // docs/architecture/retail-divergence-register.md AP-234. Do NOT
+            // remove this gate to mirror the GfxObj fix — that would draw
+            // solid-colour cell-wall faces retail never shows.
             bool hasPos = !poly.Stippling.HasFlag(StipplingType.NoPos);
             bool hasNeg = !poly.Stippling.HasFlag(StipplingType.NoNeg);
 
@@ -745,7 +776,13 @@ public sealed class MeshExtractor {
                 TextureFormat textureFormat;
                 UploadPixelFormat? uploadPixelFormat = null;
                 UploadPixelType? uploadPixelType = null;
-                bool isSolid = poly.Stippling.HasFlag(StipplingType.NoPos) || surface.Type.HasFlag(SurfaceType.Base1Solid);
+                // #426: "solid" (untextured) is a SURFACE fact, not a
+                // polygon-stippling fact — see RetailUntexturedSurfacePolicy.
+                // The old `NoPos ||` term conflated "this polygon's positive
+                // side has no UVs" with "this surface is untextured"; it also
+                // wrongly classified a NEG-side batch by the POS-side's NoPos
+                // flag, since this method is shared by both sides.
+                bool isSolid = RetailUntexturedSurfacePolicy.IsUntextured(surface.Type);
                 bool isClipMap = surface.Type.HasFlag(SurfaceType.Base1ClipMap);
                 uint paletteId = 0;
                 bool isDxt3or5 = false;