fix(upload): raise Rocket data limits to match CHUNK_SIZE

[dobby-coder]

Summary

Closes #38.

Rocket's default body-size limit for bytes, data-form, and file is 1 MiB. Since #104 landed with CHUNK_SIZE = 10 MiB, any chunk over 1 MiB gets rejected with "Data limit reached while reading the request body" — Rocket trims the body before the handler's data.open((end - start).bytes()) cap runs. The issue explicitly mentions this and the chunks >1 MiB failing uploads.

Fix

Merge framework-level limits onto Rocket::Config::figment() in rocket::custom(...):

let limits = rocket::data::Limits::default()
    .limit("bytes", (CHUNK_SIZE + 1024 * 1024).bytes())
    .limit("data-form", (CHUNK_SIZE + 1024 * 1024).bytes())
    .limit("file", (CHUNK_SIZE + 1024 * 1024).bytes());

1 MiB of headroom above CHUNK_SIZE for HTTP overhead. The per-request (end - start).bytes() cap in upload_chunk remains the authoritative limit — this change only lifts the framework floor that was clipping legitimate chunks.

rocket::Config::figment() still reads ROCKET_CONFIG / Rocket.toml before the merge, so existing deployed [global.*] settings continue to take effect.

Verification

• cargo build --release — green.
• cargo test — 5/5 pass (the existing store tests; no new tests needed for a config-only change).
• cargo clippy --all-targets — only the pre-existing useless_format warning in src/email.rs:225.

Interactive 10 MiB upload not reproduced in the workspace — cryptify's runtime needs a live PKG at startup and a client that produces a chunked Content-Range PUT, which wasn't feasible here. The issue reporter already observed the failure mode before and explicitly asked for "dynamically change datalimit based on chunk size"; this does exactly that at framework startup. Keeping as draft so a maintainer can confirm on staging.

Reviewer quickstart

git fetch origin && git checkout fix/upload-chunk-data-limit && cargo build --release