feat(server): Add X-Os-Auth as alternative auth header

[lcian]

Requests proxied through Django need the standard Authorization header for Django auth, at least until we enable and enforce auth everywhere. That header clashes with objectstore's own JWT auth.

This PR introduces a dedicated X-Os-Auth header (mirroring Relay's X-Sentry-Auth convention):

• Server: checks X-Os-Auth first, falls back to Authorization for backwards compatibility
• Rust client: sends token via X-Os-Auth instead of Authorization
• Python client: sends token via X-Os-Auth instead of Authorization

We use the X-Sn-<key> prefix for other headers (such as object metadata), so this new X-Os prefix is not consistent with it.
Still, I thought it would make sense to explicitly prefix this with X-Os to make it immediately clear what it's for (when e.g. looking at traces in Sentry) and to avoid any clashes that X-Sn-Authorization could cause, now or in the future.

A separate task, out of scope for this PR, would be to change metadata to also use X-Os as prefix, which will need a migration period where we double read before all clients are updated.

[github-actions]

Semver Impact of This PR

🟡 Minor (new features)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

New Features ✨

• (server) Add X-Os-Auth as alternative auth header by lcian in #422

Internal Changes 🔧

• (python) Pin uv_build version with upper bound by jan-auer in #420

---

_{🤖 This preview updates automatically when you update the PR.}

[jan-auer]

LGTM, thanks!

Two optional thoughts:

• I think going with x-os-auth is a good option, because we've been considering to consolidate built-in headers to x-os-* already. It's arguable that this one is not metadata of an object and still shares the same prefix, in my opinion.
• Should we leave the "default" header as Authorization? That's a standard header, so I would expect it to work with less friction.

[lcian]

1. I'll change it to X-Os-Auth.
2. The reason to make the default the new header, is that in sentry-cli this becomes simply:

    let mut builder = ClientBuilder::new(options.objectstore.url);
    if let Some(token) = options.objectstore.auth_token {
        builder = builder.token(token);
    }
    let client = builder
        .configure_reqwest(|r| {
            let mut headers = http::HeaderMap::new();
            headers.insert(http::header::AUTHORIZATION, sentry_token);
        })
        .build()?;

Otherwise, you would need to set both via configure_reqwest instead of using the built-in .token.
All other users remain the same.