DebugImage has no sourcemap variant, so events carrying JS debug IDs fail to deserialize #1267

@haithemobeidi

How do you use Sentry?

Sentry SaaS (sentry.io)

SDK version

0.42.0

Steps to reproduce

1. Build a Tauri 2 app that uses tauri-plugin-sentry, so the browser SDK
   routes envelopes to the Rust SDK over IPC.
2. Build the frontend with @sentry/vite-plugin active (default config), which
   injects per-chunk debug IDs.
3. Throw an error in the frontend.

Minimal reproducer from the original report:
https://github.com/ottosson/sentry-vite-plugin-repro

Once debug IDs are injected, @sentry/browser attaches
debug_meta.images[{ "type": "sourcemap", ... }] to every event.

Expected result

The event deserializes and is sent, as it does when the bundler plugin is absent
or sourcemaps: { disable: true } is set.

Actual result

symbolic / proguard / wasm, with no sourcemap variant and no catch-all.
Envelope::from_slice eagerly parses the event item, hits the unknown variant,
and returns InvalidItemPayload.

Downstream, tauri-plugin-sentry's if let Ok(...) has no error arm, so 100%
of frontend events are dropped with no diagnostic. Rust-side panics keep
arriving, so the project looks healthy while all JS telemetry is gone.

This was root-caused in detail by @ottosson here (2026年06月02日):
getsentry/sentry-javascript-bundler-plugins#916
Cross-posted at timfish/sentry-tauri#35

Both threads are on the bundler plugin's tracker, but the change has to happen
in this crate and I couldn't find an issue here, so I'm filing one.

Verified against master today: still no variant. Same at 0.42.0 and 0.46.2, so
a version bump doesn't help.

Suggested fix, either or ideally both:

1. Add the variant. The wire name is sourcemap, not snake_case source_map,
   so it needs an explicit #[serde(rename = "sourcemap")].
2. Add a catch-all so an unknown image type can't fail the whole event. This is
   the more valuable half: this enum deserializes data produced by other Sentry
   SDKs on independent release cycles, so a future variant will do this again.

Attribution note: both suggested fixes above are @ottosson's, from the linked
comment on bundler-plugins#916, including the Other(Map<String, Value>) catch-all
and the observation that the Context enum in this same file already has one. I'm
filing here because the change belongs in this crate and I couldn't find an issue
for it on this tracker.