feat: Add pre-signed URL support for GET/HEAD requests

[lcian]

Implements pre-signed URLs that grant time-limited access to specific objects, as an alternative to providing a JWT header.
We will need this for frontend components that rely on Objectstore to provide files (currently only snapshot images and diffs) and we could also use it for e.g. attachments downloads.

Pre-signed URLs are of the form:

/v1/objects/{usecase}/{scopes}/{key}?X-Os-Expires={unix_ts}&X-Os-KeyId={kid}&X-Os-Signature={base64url_sig}

• The signature is a Ed25519 signature of the path portion of the URL and query parameters. The signature is computed on a canonicalized combination of path and query params, to ensure that signature computation and verification are consistent.
• Pre-signed URLs are only supported for GET and HEAD requests for now. The rationale for that is to solve the immediate problem of GET requests coming from browsers, and avoid expanding the scope to PUT/POST which would have a more complex implementation (implementing those correctly would require signing (part of) the request headers).

Clients expose a presign_url utility which takes a private key and creates pre-signed URLs with a customizable TTL, 5 minutes by default.

Introduces a new objectstore-shared crate to house the shared signing logic and constants between the client and server crate. We already have objectstore-types that's similarly shared, but these are not really types, so I think a separate crate is warranted.

[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 ✨

• Add pre-signed URL support for GET/HEAD requests by lcian in #424

---

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

[lcian]

We need the pre-signed auth to take precedence, because browsers will make requests to the proxy endpoint (or to Objectstore directly, if it were exposed through an NGINX rule) with both an Authorization header and the pre-signature.

Another approach would be to try all 3 methods (2 headers + pre-signature) every time. Or even build a composite AuthContext that takes into account all authentication methods, if multiple of them are present together.
That's more resilient but also more expensive, I would prefer to avoid it.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 449747d. Configure here.}

[lcian]

This is complex:

• Needs a separate mechanism (other than the JWT) to sign and verify
• The mechanism is sensitive to encoding, ordering of query params etc.
  The only benefit that this provides is fixed-size URLs.
  The more sensible approach I will now implement is to extend JWTs to support an optional ObjectKey to scope down authorization further.