wave E stage 1: pdf_render goes native - pdfjs paints, Skia hosts

The browser was never the PDF engine - pdfjs always painted the pages;
Chrome only hosted the canvas tab. Now pdfjs-dist v6's own Node
integration (@napi-rs/canvas, its optionalDependency) hosts in-process:
same paint code, Skia canvas, zero browsers, zero temp files, no base64
hop. The whole pdf-reader runs browser-free - the Chrome gate on
pdf_render is gone.

The Skia binary (27MB per platform, exactly one per build - npm installs
only the building machine's) rides the standalone via the same
outputFileTracingIncludes pattern as pdfjs-dist. Verified: builds green
(1515), native render pinned against the real fixture (canonical
single-IDAT PNGs, dpi/72 arithmetic, page-range skipping), and the
canvas loads + paints from inside .next/standalone.

Stages 2-3 (resvg for SVG, the --browser-service demo helper) follow.

next.config.ts

@@ -55,6 +55,12 @@ const nextConfig: NextConfig = {
 		"*": [
 			"node_modules/pdfjs-dist/legacy/**/*",
 			"node_modules/pdfjs-dist/standard_fonts/**/*",
+			// Wave E (2026-10-10): pdf_render paints via @napi-rs/canvas — its
+			// platform binary (@napi-rs/canvas-<platform>-<arch>) is a dynamic
+			// optional-dep require the tracer cannot see. Builds run per-OS and
+			// npm installs only the current platform's binary, so this glob
+			// resolves to exactly one Skia binary per build.
+			"node_modules/@napi-rs/canvas-*/**/*",
 			"node_modules/@earendil-works/pi-ai/dist/providers/data/**/*",
 			"node_modules/@earendil-works/pi-agent-core/dist/**/*.json",
 		],
@@ -66,6 +72,7 @@ const nextConfig: NextConfig = {
 		"@earendil-works/pi-ai",
 		"@earendil-works/pi-agent-core",
 		"pdfjs-dist", // sources v0: bundling breaks its node fake-worker path
+		"@napi-rs/canvas", // native binding — bundling breaks the .node require
 	],
 };