Port traffic-source sanitization and queue fixes from the web SDK

.github/workflows/ci.yml

@@ -42,6 +42,43 @@ jobs:
           test -d lib/module || (echo "lib/module not found" && exit 1)
           test -d lib/typescript || (echo "lib/typescript not found" && exit 1)
 
+  version-sync:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          persist-credentials: false
+
+      # src/version.ts is generated by scripts/update-version.js during the npm
+      # `version` lifecycle, and its value is compiled into the bundle and sent
+      # as `library_version` on every event. When a release bumps package.json
+      # without running that lifecycle, the file silently keeps its old value
+      # and every event misreports which SDK produced it. The web SDK shipped
+      # four releases (1.31 through 1.33.1) all reporting 1.30.1 that way, with
+      # nothing to catch it — the release workflow only checks the git tag
+      # against package.json. This catches the drift at PR time instead.
+      - name: Verify src/version.ts matches package.json
+        run: |
+          PKG_VERSION=$(node -p "require('./package.json').version")
+          # version.ts is TypeScript, so read the literal rather than importing.
+          SRC_VERSION=$(grep -oE "version = '[^']+'" src/version.ts | sed "s/version = '//; s/'//")
+
+          echo "package.json:   $PKG_VERSION"
+          echo "src/version.ts: $SRC_VERSION"
+
+          if [ -z "$SRC_VERSION" ]; then
+            echo "::error::Could not read a version literal from src/version.ts"
+            exit 1
+          fi
+
+          if [ "$PKG_VERSION" != "$SRC_VERSION" ]; then
+            echo "::error::src/version.ts ($SRC_VERSION) does not match package.json ($PKG_VERSION). Run 'node scripts/update-version.js' and commit src/version.ts."
+            exit 1
+          fi
+
+          echo "Versions match: $PKG_VERSION"
+
   lint:
     runs-on: ubuntu-latest
     steps:

pnpm-workspace.yaml

@@ -85,9 +85,23 @@ overrides:
 #   GHSA-4x5r-pxfx-6jf8  @babel/core (LOW)      no patched version published (>=7.29.1 absent)
 #   GHSA-96hv-2xvq-fx4p  ws (HIGH)              one build-tooling ws@8.20.1 resists the >=8.21.0 override
 #   GHSA-h67p-54hq-rp68  js-yaml (MODERATE)     the only 4.x fix is a breaking major bump (5.x)
+#   GHSA-w3rx-r6r6-pgpr  image-size (HIGH)      no patched version published (see below)
+#   GHSA-5p2g-fcmc-qvqq  image-size (HIGH)      no patched version published (see below)
+#
+# image-size: both advisories name ">=2.0.3" as the patched range, but 2.0.3 has
+# never been published — npm's latest is 2.0.2, which is itself inside the
+# vulnerable "<=2.0.2" range. An override is therefore unresolvable, and there is
+# no fix to take, breaking or otherwise. It reaches the graph only as
+# metro > image-size (metro pins ^1.0.2; 1.2.1 resolves), i.e. the asset pipeline
+# of the bundler, which is build tooling and never ships in the SDK's runtime
+# output. Both advisories are decode-time infinite loops on malformed ICNS/JXL/
+# HEIF input, so exposure would require bundling a hostile image at build time.
+# Drop these two entries as soon as a patched image-size is published.
 # Revisit as upstream (react-native / metro / viem) updates these transitive deps.
 auditConfig:
   ignoreGhsas:
     - GHSA-4x5r-pxfx-6jf8
     - GHSA-96hv-2xvq-fx4p
     - GHSA-h67p-54hq-rp68
+    - GHSA-w3rx-r6r6-pgpr
+    - GHSA-5p2g-fcmc-qvqq