Add wasm-symbols upload command

[ImaneLargou]

Summary

• Adds a new datadog-ci wasm-symbols upload beta command that uploads WebAssembly (.wasm) debug info files for Error Tracking symbolication, structured the same way as the existing elf-symbols command (implemented directly in packages/base, no plugin package).
• Parses the WASM binary format directly (magic bytes, LEB128 section table, custom sections) to extract a build_id (from a build_id custom section, falling back to a SHA-256 hash of the code section per the WASM symbolication gap-analysis doc) and detect embedded (.debug_*) or external (external_debug_info) debug info.
• Uploads via multipart POST to /api/v2/srcmap with file field wasm_symbol_file, matching the server-side design in dd-go#240850, which reuses the elf_symbol_files table with symbol_source="wasm" — no new intake/table work needed here.
• No strip/split pipeline (no objcopy dependency) since v1 accepts the artifact as-is; adds --arch (wasm32/wasm64) and --source-url flags not present on elf-symbols.
• Registers the command via bin/lint-packages.ts's noPluginExceptions, updates CODEOWNERS (@DataDog/rum-browser @DataDog/rum-backend, matching sourcemaps), and documents it in the README.

Test plan

• yarn build compiles cleanly
• yarn lint passes with no errors
• yarn test packages/base/src/commands/wasm-symbols — 38 tests pass (LEB128 round-tripping, section parsing, build-ID/debug-info detection, multipart payload shape, dry-run, dedup, parameter validation), using synthetically constructed WASM buffers (no binary fixtures needed)
• Manual end-to-end verification against a real Datadog org / dd-go endpoint (server-side already merged in dd-go#240850)

🤖 Generated with Claude Code

[datadog-prod-us1-3]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 6390a8e | Docs | Datadog PR Page | Give us feedback!}

[datadog-prod-us1-3]

The PR adds a new wasm-symbols upload command for uploading WASM debug info. Code review identified one P1 behavioral defect: when a WASM file has an empty CODE section (payload.length = 0), the buildId is incorrectly computed from the empty buffer while hasCode is correctly set to false. This creates an inconsistency where buildId reflects no actual code yet fileHash is not computed, sending mismatched metadata to the server. The fix is minimal: add && codeSection.payload.length > 0 to the condition on line 165 of wasm.ts to match the hasCode check on line 163.

_{📊 Validated against 1 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit c5d7baa · What is Autotest? · Any feedback? Reach out in #autotest}

[datadog-prod-us1-3]

Empty CODE section produces mismatched buildId and fileHash

Metadata sent to server has non-empty buildId derived from empty code but empty fileHash, creating inconsistent state that could confuse symbol lookup or cause deduplication issues

Assertion details

• Input: WASM file with CODE section containing zero-byte payload and debug_info custom section
• Expected: buildId should not be computed from empty code section; both buildId and fileHash should be empty
• Actual: buildId is computed from empty buffer (sha256('')) but fileHash remains empty due to hasCode=false check

Was this helpful? React 👍 or 👎
_{🤖 Datadog Autotest · What is Autotest? · Any feedback? Reach out in #autotest}

Suggested change

	if (!metadata.buildId && codeSection) {
	if (!metadata.buildId && codeSection && codeSection.payload.length > 0) {

[cswatt]

A really small suggestion, but looks good otherwise! approving for docs

[cswatt]

Suggested change

	Upload WebAssembly (`.wasm`) debug info files to Datadog to symbolicate WASM stack traces reported by the Datadog Browser SDK.
	Upload WebAssembly debug info files (`.wasm`) to Datadog to symbolicate WASM stack traces reported by the Datadog Browser SDK.