fix: HTTP Range support on /filedownload

[dobby-coder]

Closes #153

What changed

Rocket 0.5's FileServer ignores inbound Range headers — every request gets a plain 200 with the full body and no Accept-Ranges. Browsers detect that and disable the resume button, so a flaky link on a multi-GB download means restarting from byte 0.

Replaces the FileServer mount with a custom GET /filedownload/<filename> route that:

• Validates the segment (flat UUID layout — rejects .., path separators, NUL).
• Always sets Accept-Ranges: bytes.
• With no Range header: 200 + Content-Length + full body.
• With a single Range header (bytes=N-M, bytes=N-, or bytes=-N): seeks, streams the slice, returns 206 + Content-Range: bytes start-end/total.
• Unsatisfiable / malformed ranges: 416 + Content-Range: bytes */total.
• Multi-range is intentionally unsupported — resume only needs a single range and multipart/byteranges isn't worth the complexity.

Also adds Range to the CORS allowed_headers list so browsers can send it via fetch.

Tests

• 11 parser unit tests covering the three range forms, clamping, and rejection cases.
• 7 integration tests (using the existing minimal Rocket figment harness) covering full GET, bytes=10-19, bytes=80-, bytes=-5, unsatisfiable → 416, missing file → 404, and a path-traversal attempt → 404.

cargo fmt --all -- --check, cargo test (77 passed, +19 vs. main), and cargo clippy --all-targets -- -D warnings all green locally.

Out of scope

Client-side resume UX is tracked on the website side at encryption4all/postguard-website#138.

Reviewer quickstart

git fetch origin && git checkout fix/153-download-range-support && cargo test