Report timeout message reports the timeout setting instead of how long the job waited

### Description

When a report times out, the message tells the user how long the timeout setting is, not how long their job actually waited.

In `notebooker/web/report_hunter.py`:

```python
this_cutoff = cutoff.get(result.status)
if result.job_start_time <= this_cutoff:
delta_seconds = (now - this_cutoff).total_seconds()
```

`cutoff` is built as `now - timedelta(minutes=TIMEOUT)`, so `now - this_cutoff` is always exactly the timeout setting. `result.job_start_time` is used for the comparison but never enters the calculation, so every timed-out job of a given status reports the same number.

### Reproduction

Driving the timeout branch with a stub serializer (no mongo needed), against `master`:

```
status really waited | message
Submitted to run 4 min | ... Timed out after 3 minutes 0 seconds.
Submitted to run 60 min | ... Timed out after 3 minutes 0 seconds.
Submitted to run 1440 min | ... Timed out after 3 minutes 0 seconds.
Running... 61 min | ... Timed out after 60 minutes 0 seconds.
Running... 600 min | ... Timed out after 60 minutes 0 seconds.
```

`SUBMISSION_TIMEOUT` is 3 and `DEFAULT_RUNNING_TIMEOUT` is 60, which is exactly what comes out every time. A submission stuck for a day reports three minutes.

### Two related problems in the same message

- It always says "timed out while being submitted to run", including for `PENDING` jobs, which have already started and timed out while running.
- `"{:.0f}".format(delta_seconds / 60)` rounds rather than truncates, so 3m54s would display as "4 minutes 54 seconds".

### Why the existing test did not catch it

`test_report_hunter_timeout` computes its expectation as:

```python
mins = (time_later.total_seconds() / 60) - 1
```

Both parametrized cases use `time_later` of timeout + 1 minute (4 for `SUBMITTED`, 61 for `PENDING`), so `mins` works out to 3 and 60, which is just the timeout setting again. The assertion looks like it depends on `time_later` but re-derives the constant, so it passes against the bug. A case with a longer wait fails.

### Expected

The elapsed time should be measured from `result.job_start_time`.

PR to follow.

Start in notebooker/web/report_hunter.py at the timeout branch, then read test_report_hunter_timeout and its parametrized cases. Update the elapsed-time behavior and timeout wording for submitted versus pending jobs, including the rounding case, and add a longer-wait regression test showing the actual wait duration.

Written by the indexing model from the issue text.