fix: bump @tigrisdata/storage to 3.5.2 for SigV4 path-encoding fix

[designcode]

Summary

Picks up @tigrisdata/storage@3.5.2, which fixes 403 SignatureDoesNotMatch from copy, move, and updateObject when the object key contains / or any character that requires percent-encoding (space, ?, =, etc.) and the request is signed with access-key SigV4.

This unblocks the integration tests that have been failing on main since #99 landed.

Why this only broke on CI

The custom storage HTTP client takes two different auth branches:

• OAuth / session token: skips SigV4 signing entirely.
• Access key: signs with SigV4.

PR #99 was the first time copy and move got exercised under access-key auth at scale (integration tests use TIGRIS_STORAGE_ACCESS_KEY_ID from secrets). Local development via OAuth never hit the broken signing path, so the bug only surfaced in CI.

What the SDK actually fixed

Two compounding encoding issues, both rooted in @smithy/signature-v4:

1. SignatureV4 was constructed without uriEscapePath: false. The default is the AWS-standard double-encoding scheme, but S3 (and Tigris gateway) use single-encoding — so the signer re-percent-encoded path sequences (%20 → %2520) while the gateway treated the wire path as already single-encoded.
2. Object keys in the request path and X-Amz-Copy-Source header were built with plain encodeURIComponent, which turned / into %2F. New encodeObjectKey helper splits on / and per-segment encodes, preserving separators.

Details: storage#101.

CI failures this addresses

All 10 cp/mv regression failures observed on main since the merge of #99, including:

• folder auto-detection > should auto-detect folder for cp/mv without trailing slash
• file to folder operations > should copy/move file to existing folder
• wildcard folder marker operations > should copy/move folder contents and marker using wildcard
• cp/mv - additional branches > should copy/move objects matching wildcard pattern

The 11th failure (objects set-access > should error on missing --access) is a separate, pre-existing CLI quirk in validateRequiredWhen and is not in scope here.

Test plan

• npm run format:check and npm run lint clean
• npx tsc --noEmit clean
• npm test — 659 unit/spec tests pass
• npm run build clean
• Local smoke against a real bucket with access keys:
  • cp src.txt nested/file.txt (nested key) — was 403, now succeeds
  • cp src.txt 'folder/my file.txt' (special char) — was 403, now succeeds
  • mv nested/file.txt nested/renamed.txt -f (same-bucket rename) — works
• CI integration job goes green

🤖 Generated with Claude Code

---

Note

Medium Risk
Patch-level dependency bump, but it changes request signing/encoding behavior in the storage client, which can affect object operations and authentication paths.

Overview
Updates the CLI’s @tigrisdata/storage dependency from 3.5.1 to 3.5.2 (and refreshes package-lock.json) to pick up the upstream SigV4 path/object-key encoding fix.

This is intended to resolve 403 SignatureDoesNotMatch failures for copy/move/updateObject when object keys contain / or other percent-encoded characters under access-key auth.

^{Reviewed by Cursor Bugbot for commit 280e64a. Bugbot is set up for automated code reviews on this repo. Configure here.}