Progress reports 0% for the entire job, then jumps straight to 100%

Progress is the entire reason a caller polls a job at all instead of just waiting for a single "done" webhook -- it's what a progress bar, a "3 of 5 steps complete" label, or an ETA estimate is built on. Right now, every progress update reports 0% for the job's entire runtime, until a separate, hardcoded completion write jumps straight to 100%. A frontend showing this as a progress bar shows it frozen at the start for the whole job, then teleporting to done -- indistinguishable, to a user, from "this progress bar is broken" or "this job actually hung and then suddenly finished," either of which erodes trust in the product a lot faster than an honest, accurate 40% would.

step and steps are both integers, and step is always strictly less than steps except on the loop's final iteration. Integer division truncates every intermediate ratio to 0.

1. pytest practice_tickets/tests/test_ticket_05_progress_stuck_at_zero.py -v
2. Or manually: POST /jobs with {"duration_seconds": 1.2, "steps": 4}, then poll GET /jobs/{id}?wait=2 repeatedly.
3. Observe: running 0 printed for every intermediate step, then an instant jump to -- no intermediate progress value is ever reported.

A very common Python mistake: // (floor division) instead of / (true division) when someone's converting a percentage calculation to "avoid floats," or copies a pattern from integer-bucketing code where truncation was actually the intent. Both operators are valid, both type-check fine, and the bug only shows up as output that's wrong in a way you have to actually run the code and watch to notice.

Compare step / steps (true division, giving a float between 0 and 1) against step // steps (floor division, which truncates to 0 for every step < steps). Look at what the surrounding code does with the result (rounding, multiplication by 100) to see which one the original intent was reaching for.