Fix gradient pattern stroke paint order over solid fills

[emaciel10]

When a path combines a solid fill with a shading-pattern stroke (B or B*), the inner half of the gradient outline disappears. ProcessPathPattern() paints the pattern stroke before DrawPath() paints the solid fill, so the fill covers that half of the stroke.

Defer the pattern stroke until after the remaining fill has been painted. Preserve the stroke-only path by drawing the deferred pattern when no ordinary fill/stroke work remains.

The change includes a three-page synthetic PDF template and an embedder regression test. The template uses a 10-point red-to-blue gradient stroke around a white rectangle, with B, B*, and a stroke-only S control. The test samples both halves of the outline and the white interior at 1, 2, and 4 pixels per point. It requires no fonts or customer artwork. The PR contains C++ and a text PDF template; no WASM payload is committed.

Validation

• Generated the submitted fixture with testing/tools/fixup_pdf_template.py.
• Rendered that exact fixture through released @embedpdf/pdfium 2.15.1, native revision 73a041a5c1aaffa09ebb64f1981ff501cb91a41c, and a locally available rebuilt 2.15.1 WASM with this same paint-order change.
• Stock: the inner-stroke sample is white (green channel 255) for both B and B* at every scale; the outer half remains colored.
• Fixed: both stroke samples have green channel 0 and the interior stays white for all nine page/scale combinations. The S control passes on both binaries.
• The same correction has also been verified locally on affected real-world artwork; only the independent synthetic reproducer is included here.
• git diff --check passes.

Current embedpdf/main has not been rebuilt locally. This checkout lacks the native depot_tools/GN/Ninja setup, so the new C++ embedder test and full native suites are not claimed as passed. The unchanged faulty ProcessPath() sequence is present at base ed2f716e5381e34f096cc1e50e4259a55998d391. Please run the current-head AGG/Skia render checks before merging. This is a draft for native validation and review.

Targeted native check after configuring/building the project:

autoninja -C out/Debug pdfium_embeddertests
out/Debug/pdfium_embeddertests --gtest_filter='FPDFRenderPatternEmbedderTest.ShadingStrokePaintsAfterSolidFill'

Release request

Could this also be backported to embedpdf/v2 and released through the maintained @embedpdf/pdfium 2.15.x package? The aim is to consume the official package instead of carrying an application-owned native binary. A fix only in the newer runtime would leave v2 consumers with the existing defect.

This is a native PDFium rendering correction rather than a wrapper change. I would also welcome guidance on taking the change through PDFium's Gerrit/CLA process, or a maintainer-led upstream port.