feat: Add WASM support

[darrell-roberts]

Description

This adds WASM support to the sentry-* crates.

New crate: sentry-time

• Brand-new internal crate (sentry-time/) exposing now_system_time() -> SystemTime.
• Non-WASM: delegates to SystemTime::now().
• WASM (target_arch = "wasm32"): builds SystemTime from chrono::Utc::now() (since SystemTime::now() panics on wasm32-unknown-unknown).
• Added to workspace members in root Cargo.toml.

Replace SystemTime::now() call sites

All call sites that produced a current timestamp now go through sentry_time::now_system_time (or are #[serde(default = "sentry_time::now_system_time")]):

• sentry-types/src/auth.rs, protocol/session.rs, protocol/v7.rs (Breadcrumb, Event, Span, Transaction defaults + Span::finish/Transaction::finish).
• sentry-core/src/lib.rs (re-exports sentry_time as #[doc(hidden)] pub use), logger.rs (4 macro arms now use $crate::sentry_time::now_system_time()), performance.rs, session.rs.
• sentry-log/src/converters.rs.

Instant → chrono for elapsed time (WASM-incompatible Instant)

• sentry-core/src/batcher.rs: Instant/std::time::Duration swapped for chrono::{DateTime<Utc>, Duration}. FLUSH_INTERVAL now Duration::seconds(5); last_flush.elapsed() becomes Utc::now() - last_flush; .checked_sub(...).to_std() bridges back to std::time::Duration for cvar.wait_timeout.
• sentry-core/src/session.rs: Session.started: Instant → DateTime<Utc>; flusher loop converted analogously, chrono::Duration::from_std(FLUSH_INTERVAL).

Platform-gated deps

• sentry-contexts/Cargo.toml: hostname moved under cfg(not(target_arch = "wasm32")); uname gated on cfg(all(not(windows), not(target_arch = "wasm32"))).
• sentry-contexts/src/utils.rs: server_name() returns None on WASM; os_context() on WASM returns OsContext { name: Some("WASM"), ..default() }.

Cargo updates

• sentry-core, sentry-types, sentry-log add sentry-time path dep.
• sentry-core and sentry-types add chrono = "0.4.44" direct dep.
• sentry-types flips time crate to default-features = false (drops std-only timer features for WASM).
• Cargo.lock: adds sentry-time package; chrono now pulls js-sys + wasm-bindgen.

Notes / things worth flagging

• New pub use sentry_time in sentry-core is #[doc(hidden)] — fine, but it's part of the public macro surface (needed by the logger.rs macros). Removing it later would be breaking.
• WASM os_context() text is hard-coded "WASM"; left a // TODO: What other options are available? for server_name().
• No tests added for WASM behavior (no wasm32 test target wired up here).

Issues

Reminders

• Add GH Issue ID & Linear ID (if applicable)
• Add an entry to CHANGELOG.md, following the format of existing entries
• The PR title should use Conventional Commits style (feat:, fix:, ref:, meta:, etc.)
• Useful links for external contributors: Sentry SDK development docs, Discord community

[sdk-maintainer-bot]

This PR has been automatically closed. The referenced issue does not show a discussion between you and a maintainer.

To avoid wasted effort on both sides, please discuss your proposed approach in the issue first and wait for a maintainer to respond before opening a PR.

Please review our contributing guidelines for more details.

[LeoniePhiline]

Amazing work, thank you!

I would like to recommend using jiff instead of chrono. It has WASM support via the js crate feature.

jiff is highly optimized and just better than chrono all around.

[LeoniePhiline]

@szokeasaurusrex Would you mind re-opening the PR? It was merely auto-closed because the link to #226 is missing in the PR description.

[szokeasaurusrex]

Hi @LeoniePhiline, thanks for following up.

As I suggested in my comment on #226, we currently do not have capacity to work on WASM support ourselves, or to properly review PRs that aim to add it.

While WASM support is still something we want for the Rust SDK, we do not have a concrete timeline right now.

---

Because of the above, I would prefer to keep this PR closed. Reopening it would create the expectation that the team can review it in the near future, which unfortunately is not the case. I would have suggested closing the PR myself had the bot not already done so.

Thanks again to @darrell-roberts for putting this together; it may still be useful as input when we get to WASM support.

To keep the discussion in one place, please use #226 for further discussion about WASM support. I am going to lock this PR conversation for that reason.

[szokeasaurusrex]

Also @LeoniePhiline, just so you are aware, we have deactivated that PR-closing bot after receiving feedback that it was closing PRs too aggressively, so it should no longer be an issue