TTL selection is inverted between running and terminal jobs

This bug breaks the TTL mechanism in both directions at once. A job that's still actively running can disappear from Redis before it finishes, because it's getting the short result TTL (meant only for finished results) instead of the long pending TTL -- a client polling a long-running job would suddenly get 404s partway through, indistinguishable from the job genuinely having vanished. And a completed job's result sticks around far longer than configured, because it's getting the long pending TTL instead of the short result TTL -- a promise this project's own README documents as a "privacy/cleanup guarantee" for whatever's in a job's result, quietly broken for every single completed job.

This is backwards: a terminal status (completed/failed/cancelled) gets pending_ttl_seconds (meant for jobs still in flight), and a non-terminal status gets result_ttl_seconds (meant only to apply once a job is actually finished).

1. pytest practice_tickets/tests/test_ticket_09_ttl_selection_inverted.py -v
2. Or manually: configure Settings(result_ttl_seconds=1, pending_ttl_seconds=30), submit a job with duration_seconds: 4, wait 2 seconds, then GET /jobs/{id}?wait=0.
3. Observe: 404 job not found or result expired, for a job that is only 2 seconds into a 4-second run.

The condition itself (status in TERMINAL_STATUSES) is correct -- it's exactly the right thing to branch on. The bug is purely in which value got assigned to which branch, the kind of mistake that's trivially easy to introduce (and just as easy to miss on a skim) because the line reads as sensible either way. This also fails tests/test_expiry.py::test_completed_job_expires_after_its_ttl in the project's own suite.

Look at what result_ttl_seconds and pending_ttl_seconds are each documented to protect (see their docstrings in app/config.py), and check which one is currently paired with status in TERMINAL_STATUSES versus its else.