Wait correctly between token requests

A slow_down adds five seconds permanently for this polling session.

• When authorization_pending is returned, the client SHOULD repeat its token request. Before each new request it MUST wait at least interval seconds, or five seconds if the device response omitted interval, including any slow_down increases (§§3.2,3.5). Polling is not a tight retry loop.
• On slow_down, authorization is still pending, but the interval MUST increase by five seconds for this and all subsequent requests. It is neither reset on the next authorization_pending response nor merely a one-time five-second pause (§3.5).
• On a connection timeout, clients MUST reduce polling frequency before retrying. Exponential backoff, such as doubling the interval, is RECOMMENDED rather than mandatory. A timeout is a transport event, not an OAuth slow_down error (§3.5).
• The worked timeline uses a five-second starting interval, successive response times 0/5/10/20 seconds, and a recommended doubling example after timeout. Waiting is anchored conservatively at each response/timeout timestamp. No server latency, real clock, retry jitter or universal timeout policy is specified.
• Only authorization_pending and slow_down errors allow continued polling. Any other error code MUST stop polling. Success also ends this example polling session. Expiration and denial are not instructions to keep trying the same code (§3.5). A negotiated return-channel alternative is outside this specification.