fix: validate cryptifytoken header in upload_finalize

[dobby-coder]

Summary

upload_finalize was not validating the cryptifytoken header despite the frontend sending it with every finalize request. Anyone who knew a valid upload UUID could finalize an upload without possessing the correct token, bypassing the token chain established during init and upload_chunk.

This adds the same validation that upload_chunk already performs: the header is extracted, and the request is rejected with 400 Bad Request if it's missing or does not match state.cryptify_token.

Why draft

There is no existing integration test suite that exercises the upload handlers, so I could not add a regression test. Verified locally via cargo build --release and cargo test. A maintainer should confirm the change behaves as expected end-to-end with the frontend.

How to verify

1. Start an upload and obtain a UUID from POST /fileupload/init.
2. Upload all chunks normally.
3. Send POST /fileupload/finalize/<uuid> with a wrong or missing cryptifytoken — should now return 400 Bad Request instead of succeeding.
4. Re-send with the correct token — should succeed as before.

Closes #45

[rubenhensen]

add some tests

[rubenhensen]

add some tests

[dobby-coder]

Added 6 unit tests in b6696a4:

• Extracted the token-check into a small check_cryptify_token helper used by both upload_chunk and upload_finalize so the new path is exercised directly.
• Tests cover: matching token accepted, mismatched token rejected with BadRequest, empty header rejected, case-sensitive comparison, plus two tests for compute_hash (determinism + differing tokens).

All green via cargo test (6 passed). No integration-level test yet — the handlers require a live PKG + Unsealer, which is out of scope for a unit test pass. This keeps the PR focused on the security fix with direct coverage of the comparison logic.

[dobby-coder]

Dobby has rebased this on top of main (which had diverged 4 commits with the tiered-limits work) and added tests as requested.

The branch previously had two commits from two different dobby variants running in parallel — both have been preserved and consolidated into a single commit with all the tests from both:

• FinalizeHeaders extractor tests (4): regression tests that verify the extractor returns 400 when CryptifyToken is missing, Content-Range is missing, or Content-Range is malformed — and extracts both correctly on success. These cover the attack surface the fix closes.
• ContentRange parser tests (5): well-formed, wildcard range, wildcard size, wrong unit, empty string.
• check_cryptify_token tests (4): match / mismatch / empty-header / case-sensitive. The comparison itself is also extracted into a shared helper so the two call sites (upload_chunk and upload_finalize) can't drift.
• compute_hash tests (2): determinism and token-sensitivity.

All 20 tests pass locally (cargo test), cargo build --release succeeds, and cargo clippy --all-targets shows only the pre-existing useless_format warning in src/email.rs:225 (unrelated to this PR). What wasn't tested: the upload_finalize handler end-to-end with a mismatched token — doing so requires standing up a PKG + VerifyingKey, which wasn't feasible in this session. The extracted helper and extractor-level tests cover the security-critical comparison, and the existing upload_chunk tests exercise the same helper.

Will flip to ready-for-review once CI is green.

[dobby-coder]

Dobby sees the approval! Master rubenhensen has approved Dobby's fix for the cryptifytoken validation in upload_finalize, and Dobby sees the pull request has already been merged into main. Dobby is delighted to have helped close #45! 🧦

Dobby will now update his notes so that future Dobbys remember the token-chain lesson from this fix.