Characterize file storage, job lifecycle, and destructive operations

[DenWin]

Parent testing program: #16. Blocked by #17 and dependent on the harness in #18.

Goal

Build a safety net around upload, job state, results, downloads, deletion, and scheduled cleanup before extracting deeper storage/job modules.

Required tests

Upload and paths

• Valid single and multiple uploads.
• Missing/invalid job cookie and nonexistent job.
• User owns the target job.
• Unicode, spaces, reserved characters, empty sanitized names, traversal attempts, and duplicate sanitized names.
• Write failure and partial batch failure behavior.
• Server-side file-count and size enforcement when introduced.

Conversion submission and status

• Valid target/converter request.
• Missing auth/job, malformed JSON file list, non-array/empty list, unsafe target, unknown converter, and missing upload.
• Job transitions from not-started to pending to completed/failed.
• Background rejection and partial completion behavior.
• Redirect and progress polling contract.

Results, history, and downloads

• Only the owning user can view results/history/downloads.
• Missing jobs/files return intentional status responses.
• Download filename decoding/sanitization and media response.
• Archive creation includes expected outputs, excludes archive files, and cannot traverse paths.
• Result counts/statuses match database records.

Deletion and cleanup

• Single file, single job, and multi-job ownership.
• Missing paths, filesystem failures, database failures, and partial multi-delete result reporting.
• Cleanup age boundary, directories removed, and database rows removed.
• No operation can delete outside the configured storage root.
• Repeated delete/cleanup behavior is explicitly idempotent or intentionally reported.

Preliminary-test rule

Where direct route testing is blocked by global database/filesystem imports, first add end-to-end characterization with temporary mounted data. Only then introduce storage/repository adapters; do not mock away path containment or ownership behavior.

Acceptance criteria

• Critical ownership and path-containment tests run in the PR gate.
• Destructive tests operate only inside verified temporary roots.
• Partial failure semantics are specified and tested.
• Database and filesystem outcomes are asserted together.
• Controlled faults prove critical tests fail when ownership or containment checks are removed.