Adding an SVG image containing `<text>` with different font styles leads to non-deterministic compilation results.

Description

Steps to reproduce: compile this document multiple times to PDF (with Typst 0.13.1) and compare the results:

#set document(date: none)
#set page(width: auto, height: auto, margin: 0pt)

#image(bytes(`
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="15pt" height="9pt" viewBox="0 0 15 9" version="1.1" id="svg5"
   xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
   <defs id="defs2" />
   <g id="layer1">
      <text style="font-size:12px;line-height:1.25;font-family:sans-serif;stroke-width:0.749947"
         xml:space="preserve" x="0.5" y="7.5" id="text113">a</text>
      <text
         style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:12px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';stroke-width:0.750067"
         xml:space="preserve" x="7.5" y="7.5" id="text167">a</text>
   </g>
</svg>
`.text.trim()))

The SVG is out of inkscape, lightly edited for terseness.

Expected result: all compilations result in byte-identical results.
Actual result: it seems that PDF sections relating to the two font variants can be switched non-deterministically. (The visual result is identical.)

Here are some excerpts from the diff of two resulting PDFs (it seems like I can't attach them, but it's fairly simple to reproduce):

diff --git a/a.pdf b/a.pdf
--- a/a.pdf
+++ b/a.pdf
@@ -11,8 +11,8 @@
   /Filter /FlateDecode
   /Resources <<
     /Font <<
-      /fo0 4 0 R
-      /fo1 5 0 R
+      /fo1 4 0 R
+      /fo0 5 0 R
     >>
     /ColorSpace <<
       /cs0 [/ICCBased 6 0 R]
@@ -30,7 +30,7 @@ endobj
 <<
   /Type /Font
   /Subtype /Type0
-  /BaseFont /UPVDXZ+LibertinusSerif-Regular-Identity-H
+  /BaseFont /ZQVXKE+LibertinusSerif-Bold-Identity-H
   /Encoding /Identity-H
   /DescendantFonts [7 0 R]
   /ToUnicode 8 0 R
@@ -41,7 +41,7 @@ endobj
 <<
   /Type /Font
   /Subtype /CIDFontType0
-  /BaseFont /UPVDXZ+LibertinusSerif-Regular
+  /BaseFont /ZQVXKE+LibertinusSerif-Bold
   /CIDSystemInfo <<
     /Registry (Adobe)
     /Ordering (Identity)
...
@@ -128,7 +125,7 @@ endobj
 <<
   /Type /Font
   /Subtype /Type0
-  /BaseFont /ZQVXKE+LibertinusSerif-Bold-Identity-H
+  /BaseFont /UPVDXZ+LibertinusSerif-Regular-Identity-H
   /Encoding /Identity-H
   /DescendantFonts [11 0 R]
   /ToUnicode 12 0 R
@@ -139,7 +136,7 @@ endobj
 <<
   /Type /Font
   /Subtype /CIDFontType0
-  /BaseFont /ZQVXKE+LibertinusSerif-Bold
+  /BaseFont /UPVDXZ+LibertinusSerif-Regular
   /CIDSystemInfo <<
     /Registry (Adobe)
     /Ordering (Identity)
...

Reproduction URL

No response

Operating system

Linux

Typst version

• I am using the latest version of Typst

Start with the supplied Typst reproduction and compile it repeatedly with Typst 0.13.1, then compare the generated PDFs and inspect the font-related sections shown in the diff. Done means repeated compilations produce byte-identical PDF output while preserving the visually identical result.