fix(sigv4): use encoded request path for inbound signature verification

[alukach]

Problem

Uploading an object whose key contains a character the client percent-escapes — e.g. a space (foo bar → foo%20bar) — fails with 403 SignatureDoesNotMatch:

[WARN] multistore::auth::sigv4: SigV4 signature mismatch
canonical_request=PUT
/alukach/upload-tests/foo bar     <-- literal space
...

Root cause

SigV4's canonical URI is the percent-encoded path the client signed. RequestParts::from_web_sys decodes the request path (correct for bucket/key routing — operation.key() needs the decoded foo bar), and we were passing that same decoded path as the signing_path. So the server rebuilt its canonical request with a literal space while the client (aws-sdk-js) signed %20 → signatures never match.

The outbound leg was already correct: build_backend_url hands the decoded key to url::Url::parse, which re-encodes the space to %20 consistently for both the forwarded request and its signature.

Fix

Recover the raw encoded path from the request URL via http::Uri::path() (which does not decode) and use it as the signing path. Routing/bucket-key parsing keeps the decoded path. Handles all escaped characters, not just spaces; falls back to the decoded path if the URL won't parse.

Tests

• New characterization test in tests/routing.rs pinning the http behavior the fix relies on (Uri::path() preserves %20).
• Full native suite + wasm clippy/check pass via the pre-commit hook.

⚠️ Verified locally only (the fetch handler is wasm-only and can't be unit-tested natively). Needs a staging deploy to confirm the real foo bar upload now succeeds.

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 4m 13s —— View job

---

Reviewing PR #176

• Gather context (diff, changed files)
• Review src/lib.rs changes
• Review tests/routing.rs changes
• Post final review

[github-actions]

🚀 Latest commit deployed to https://source-data-proxy-pr-176.source-coop.workers.dev

• Date: 2026-07-01T03:05:20Z
• Commit: 4a82658