Fix font path breaking every PDF render inside the Payload backend (v0.2.8)

fonts.ts resolved the vendored Liberation Sans .ttf files via
`new URL('./assets/fonts/...', import.meta.url).pathname` — Next.js's
Turbopack/webpack bundler statically rewrites exactly that expression
into its own hashed static-asset system. Harmless in the frontend's own
build, but the Payload backend is also a Next.js app consuming this
package as a node_modules git dependency, where the hash referenced in
the compiled server code didn't match what was actually emitted to disk
— every invoice/correction-invoice admin download failed with
ENOENT: .../LiberationSans-Regular.<hash>.ttf. Not a cache issue,
reproduced identically after a from-scratch --no-cache rebuild. Fixed by
resolving the path via fileURLToPath(import.meta.url) + path.join
instead, which Turbopack does not special-case.

src/fonts.ts

@@ -1,4 +1,6 @@
 import { Font } from "@react-pdf/renderer";
+import { fileURLToPath } from "node:url";
+import { dirname, join } from "node:path";
 
 // Registered once here (not inline in invoicePdf.tsx/correctionInvoicePdf.tsx)
 // and imported by both for its side effect — avoids double-registering the
@@ -12,10 +14,27 @@ import { Font } from "@react-pdf/renderer";
 // via Font.register. Liberation Sans is metrically identical to Helvetica/
 // Arial (SIL Open Font License, see src/assets/fonts/LICENSE-OFL.txt), so
 // embedding it doesn't shift any existing layout.
+//
+// Path built via fileURLToPath+join, NOT `new URL('./file', import.meta.url)`
+// — that literal pattern is exactly what Next.js's Turbopack/webpack bundler
+// statically detects and rewrites into its own hashed static-asset system
+// (`.next/server/assets/<hash>.ttf`). When this package is consumed as a
+// node_modules git dependency inside a Next.js/Payload server build, that
+// rewritten hash ended up not matching the file Turbopack actually emitted,
+// so every PDF render at runtime failed with `ENOENT: .../LiberationSans-
+// Regular.<hash>.ttf` — reproduced even with a from-scratch `--no-cache`
+// rebuild, so it wasn't a stale-cache issue, the asset-hashing itself was
+// wrong for this consumption path. This file only runs server-side (a PDF
+// renderer has no reason to ever reach a client bundle) and Turbopack does
+// not apply the same special-cased URL rewriting to a plain
+// fileURLToPath/path.join construction, so this sidesteps the bug entirely
+// while still resolving to the correct absolute path at runtime.
+const fontsDir = join(dirname(fileURLToPath(import.meta.url)), "assets/fonts");
+
 Font.register({
   family: "Liberation Sans",
   fonts: [
-    { src: new URL("./assets/fonts/LiberationSans-Regular.ttf", import.meta.url).pathname, fontWeight: "normal" },
-    { src: new URL("./assets/fonts/LiberationSans-Bold.ttf", import.meta.url).pathname, fontWeight: "bold" },
+    { src: join(fontsDir, "LiberationSans-Regular.ttf"), fontWeight: "normal" },
+    { src: join(fontsDir, "LiberationSans-Bold.ttf"), fontWeight: "bold" },
   ],
 });