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>

tests/AcDream.Core.Tests/Meshing/GfxObjMeshTests.cs

@@ -247,4 +247,56 @@ public class GfxObjMeshTests
 
         Assert.Empty(subs);  // no valid polygons → no sub-meshes
     }
+
+    /// <summary>
+    /// #426 (2026-08-23, Holtburg windmill axle 0x010010CE): a NoPos-flagged
+    /// polygon ("this side has no texture coordinates", acclient.h:7386) is
+    /// NOT "no positive face" — every solid-colour polygon carries NoPos.
+    /// Before the fix, <c>hasPos = !Stippling.NoPos</c> dropped this quad
+    /// entirely, producing zero vertices. GfxObjMesh.Build doesn't branch on
+    /// Surface.Type at all (that classification — "is this untextured" —
+    /// lives in RetailUntexturedSurfacePolicy and is consumed by
+    /// MeshExtractor, which is what actually decides solid-vs-textured
+    /// rendering), so a NoPos polygon over a "solid" surface and a NoPos
+    /// polygon over a "textured" surface are IDENTICAL from this method's
+    /// point of view — both are proven by this one case.
+    /// </summary>
+    [Fact]
+    public void Build_NoPosQuad_StillEmitsPositiveSideVerticesAndIndices()
+    {
+        var gfx = new GfxObj
+        {
+            Surfaces = { 0x08000000u },
+            VertexArray = new VertexArray
+            {
+                Vertices =
+                {
+                    // No UVs at all — matches a real solid-colour polygon's
+                    // vertices, which carry no UV entries because nothing
+                    // ever samples them.
+                    [0] = new SWVertex { Origin = new(0, 0, 0) },
+                    [1] = new SWVertex { Origin = new(1, 0, 0) },
+                    [2] = new SWVertex { Origin = new(1, 1, 0) },
+                    [3] = new SWVertex { Origin = new(0, 1, 0) },
+                },
+            },
+            Polygons =
+            {
+                [0] = new Polygon
+                {
+                    Stippling = StipplingType.NoPos,
+                    PosSurface = 0,
+                    NegSurface = -1,
+                    VertexIds = { 0, 1, 2, 3 },
+                    // No PosUVIndices — NoPos means there ARE none on the wire.
+                },
+            },
+        };
+
+        var sub = GfxObjMesh.Build(gfx).Single();
+
+        Assert.Equal(4, sub.Vertices.Length);
+        Assert.Equal(6, sub.Indices.Length); // fan-triangulated quad, 2 triangles
+        Assert.All(sub.Vertices, v => Assert.Equal(Vector2.Zero, v.TexCoord));
+    }
 }

tests/AcDream.Core.Tests/Meshing/RetailUntexturedSurfacePolicyTests.cs

@@ -0,0 +1,42 @@
+using AcDream.Core.Meshing;
+using DatReaderWriter.Enums;
+
+namespace AcDream.Core.Tests.Meshing;
+
+/// <summary>
+/// #426 (2026-08-23, the Holtburg windmill axle 0x010010CE): pins the two
+/// predicates that replaced the buggy <c>isSolid = NoPos || Base1Solid</c>
+/// extraction rule and the "retail never draws untextured subsets" #119
+/// misconception. See RetailUntexturedSurfacePolicy.cs for the full retail
+/// citations (D3DPolyRender::DrawMesh / DrawBuilding / DrawEnvCell).
+/// </summary>
+public sealed class RetailUntexturedSurfacePolicyTests
+{
+    [Theory]
+    [InlineData(SurfaceType.Base1Solid, true)] // solid-colour — untextured
+    [InlineData((SurfaceType)0, true)] // neither bit set — untextured
+    [InlineData(SurfaceType.Base1Image, false)] // BASE1_IMAGE (0x2) — textured
+    [InlineData(SurfaceType.Base1ClipMap, false)] // BASE1_CLIPMAP (0x4) — textured
+    [InlineData(SurfaceType.Base1Image | SurfaceType.Base1Solid, false)] // both bits — retail's literal (type & 6) != 0 still calls this textured
+    [InlineData(SurfaceType.Base1Image | SurfaceType.Additive, false)] // unrelated flags alongside a textured bit stay textured
+    public void IsUntextured_MatchesRetailBitmask(SurfaceType type, bool expected)
+    {
+        Assert.Equal(expected, RetailUntexturedSurfacePolicy.IsUntextured(type));
+    }
+
+    [Theory]
+    // (isBuildingShell, isUntextured) -> draws
+    [InlineData(false, true, true)] // ordinary object, solid subset — retail draws it (#426's own bug)
+    [InlineData(true, true, false)] // building shell, solid subset — retail's DrawBuilding skips it
+    [InlineData(false, false, true)] // ordinary object, textured subset — always drawn
+    [InlineData(true, false, true)] // building shell, textured subset — the shell gate only touches untextured subsets
+    public void Draws_MatchesRetailBuildingShellGate(
+        bool isBuildingShell,
+        bool isUntextured,
+        bool expectedDraws)
+    {
+        Assert.Equal(
+            expectedDraws,
+            RetailUntexturedSubsetPolicy.Draws(isBuildingShell, isUntextured));
+    }
+}