SoftGPU: Add the secondary color on the portable triangle path

Without SSE or NEON, triangle pixels got the secondary color in place of
the primary one plus it, so lit triangles came out black. It showed as
the "unexplained" known failures on riscv64 and loongarch64, and broke
the new gpu/lighting/shademap there. Reproduced on arm64 by building
without NEON.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

GPU/Software/Rasterizer.cpp

@@ -1159,7 +1159,7 @@ void DrawTriangleSlice(
 						int32x4_t sec = vsetq_lane_s32(0, sec_color[i].ivec, 3);
 						prim_color[i].ivec = vaddq_s32(prim_color[i].ivec, sec);
 #else
-						prim_color[i] = Vec4<int>(sec_color[i], 0);
+						prim_color[i] += Vec4<int>(sec_color[i], 0);
 #endif
 					}
 				}

test.py

@@ -512,17 +512,9 @@ known_failures = {
     # The ISA returns the canonical NaN (0x7fc00000) from every operation, never the operand's
     # NaN, so a negative or signaling NaN input loses its sign and payload. Everything else passes.
     "cpu/fpu/roundmode",
-    # The software renderer's output differs from the reference by the same amount on both of
-    # these architectures, despite them using completely different SIMD paths. Unexplained.
-    "gpu/clipping/homogeneous",
-    "gpu/commands/cull",
-    "gpu/primitives/triangles",
   ],
   "loongarch64": [
     "cpu/fpu/fpu",
-    "gpu/clipping/homogeneous",
-    "gpu/commands/cull",
-    "gpu/primitives/triangles",
   ],
 }