GET /jobs/{id}'s wait clamp uses max() instead of min(), so wait is never actually capped

This single flipped function call breaks two guarantees the whole API is built around, at the same time. First, a wait above the server's cap is supposed to be capped at it -- with max() instead of min(), a caller asking for more than the cap gets exactly what they asked for, uncapped, so the entire proxy-safety mechanism does nothing. Second, a wait below the cap -- including 0, including omitting wait entirely -- gets silently forced up to the cap. wait being optional exists specifically so a plain status check never hangs; with this bug it always hangs, for up to max_wait_seconds. Any monitoring dashboard, health-check script, or simple client library polling the "naive" way silently turns into a long-poller itself, and a client library with a small connection pool making frequent "just check the status" calls would exhaust that pool under normal use.

max() raises any wait_seconds below the ceiling up to the ceiling, instead of leaving values under the ceiling alone and only clamping values above it.

1. pytest practice_tickets/tests/test_ticket_07_wait_seconds_never_capped.py -v
2. Or manually: configure Settings(max_wait_seconds=10.0), submit a job with duration_seconds: 20, then GET /jobs/{id} with no wait param at all.

min/max mixups are an easy typo to make and an easy one to miss on review, because both read as grammatically plausible: "clamp the wait to the max" sounds right whether you mean "cap it at the max" (min) or "raise it to the max" (max). The two only diverge in behavior for inputs on one specific side of the ceiling, which is exactly why casual testing (submit a job, poll it with a reasonable wait a few times, see it work) can miss this entirely -- it also fails two tests in the project's own tests/ suite, including the naive-vs-long-poll signature comparison, because this bug turns every plain, un-waited GET into an accidental long-poll too.

Work out, from first principles, what each of min(requested, ceiling) and max(requested, ceiling) does at both ends of the range: a requested value below ceiling, and one above it. Compare that against what app/config.py's comments say both max_wait_seconds and default_wait_seconds are for.