fix(connection): retry transient 429 / 5xx instead of failing the request

[bartolije]

Closes #61 (504 during command polling) and addresses #63 (429 marking every Porsche Connect entity Unavailable until HA restart).

Per the maintainer comment on #63:

"I'll look into having some automatic retry after some time to get it
up again."

And the body of #61:

"should not cause an exception (at least not until having retried one
or two times). Note that the remote service call itself was
successful, it was only the call for status that timed out."

Implementation:

• Connection.request retries up to 3 times on {429, 502, 503, 504}.
• The server-provided Retry-After header is respected when present (RFC 9110 §10.2.3) and is a positive integer of seconds.
• Otherwise: exponential backoff (1s, 2s, 4s) with up to 0.3s of jitter to spread out concurrent retries.
• Per-retry delay capped at 30s so a misbehaving server can't pin a caller for minutes.
• Non-transient 4xx (e.g. 400 / 401 / 404) still raise immediately via PorscheExceptionError — same behaviour as before.
• Token-lock acquisition moved out of the retry loop; only the actual HTTP call is retried (ensure_valid_token is a fast no-op when the token is still valid).

Concrete repro of the previous behaviour:

>>> # Previously, a single 504 from /commands/{id} would crash the
>>> # coordinator update, marking every HA entity Unavailable.
>>> # After this patch, the 504 is retried up to 3 times before
>>> # bubbling up.