fix(proguard): restore leading slash in DIF assemble name

[gabriellanata]

Summary

proguard upload fails server-side assembly for every upload, on every version since the
command was added in #1074 — including main and the latest release (0.42.2). The mapping is
chunked and uploaded fine, but the DIF is never created, so nothing ever symbolicates.

Error: ProGuard mapping assembly failed
  Endpoint: projects/<org>/<project>/files/difs/assemble/
  Invalid debug information file: unsupported object file format

Every HTTP call up to that point returns 200 — the failure only appears inside the
per-checksum detail field of the assemble response body, which makes it easy to misdiagnose
as an auth, org/project, or mapping-file problem.

Root cause

In packages/cli/src/lib/api/proguard.ts:165, uploadProguardMappings builds the
files/difs/assemble/ request body with:

name: `proguard/${cm.mapping.uuid}.txt`,

Legacy sentry-cli (Rust) names the same DIF entry with a leading slash:

// src/utils/proguard/mapping.rs
fn name(&self) -> Cow<'_, str> {
    format!("/proguard/{}.txt", self.uuid)
}

The leading slash is load-bearing. ProGuard/R8 mappings are plain text with no magic bytes, so
the server identifies them purely by the /proguard/ prefix in the request name
(sentry/src/sentry/models/debugfile.py):

_proguard_file_re = re.compile(r"/proguard/(?:mapping-)?(.*?)\.txt$")

The full failure path:

1. tasks/assemble.py → detect_single_dif_from_path(temp_file.name, name=name, debug_id=debug_id)
2. models/debugfile.py → proguard_id = _analyze_progard_filename(path) or _analyze_progard_filename(name)
   • name is proguard/<uuid>.txt, which _proguard_file_re.search() does not match — no leading slash.
   • path is the server's own temp file, so it cannot match either.
   • proguard_id is None, and ProGuard detection is skipped entirely.
3. Control falls through to generic native-object detection: Archive.open(path) on a text
   file raises SymbolicError, which becomes
   raise BadDif("Invalid debug information file: %s" % e).
4. tasks/assemble.py catches BadDif and records
   set_assemble_status(..., ChunkFileState.ERROR, detail=e.args[0]).
5. This CLI's checkAssembleResponse surfaces that detail as the error above.

The expected shape is documented in the server source, in the docstring of
get_debug_id_from_dif_request right next to the regex:

Most DIF uploads provide an explicit debug_id. ProGuard mappings instead encode it in the
request name such as /proguard/mapping-<uuid>.txt.

Since the mapping- prefix is optional in the regex, /proguard/<uuid>.txt — exactly what the
legacy CLI sends — is the correct minimal form.

Fix

Add the leading slash back, matching the legacy protocol byte-for-byte as originally intended
by #1074. No other divergence: the UUID itself is already correct
(uuidv5(uuidv5(NAMESPACE_DNS, "guardsquare.com"), <raw bytes>), verified against the legacy
fixtures).

Test plan

• Added a regression test in test/lib/api/proguard.test.ts (uploadProguardMappings > assemble request names each mapping with a leading-slash /proguard/ path) that mocks the
  chunk-upload and assemble endpoints and asserts the exact DIF name sent.
• Confirmed the new test fails without the fix (proguard/<uuid>.txt) and passes with it
  (/proguard/<uuid>.txt).
• pnpm vitest run test/lib/api/proguard.test.ts test/commands/proguard — 18/18 passing.
• Reproduced the failure against production Sentry with sentry proguard upload on 0.40.0
  and 0.41.0. The same mappings, from the same CI pipeline, assembled successfully through
  legacy sentry-cli 3.6.2 before it was swapped for this CLI — the assemble name is the only
  relevant difference between the two.

[vercel]

@gabriellanata is attempting to deploy a commit to the Sentry Team on Vercel.

A member of the Team first needs to authorize it.

[gabriellanata]

ptal @BYK