Fixed chats that are too large being sent again and again

[j-erler]

When a chat grows past what the model accepts, some providers answer with 413 Request Entity Too Large instead of describing the problem in a 400 body. BaseProvider.SendRequest recognizes a full context window only in its BadRequest branch, by looking for "context" and "token" in the error body, so a 413 matches none of the status code branches and falls through to the retry loop.

That loop then resends the very same oversized request six times with growing delays — 4, 16, 64, and then 90 seconds each, so the user waits about six minutes and is finally told "Even after 6 retries, there were some problems with the request", which explains nothing.

The chat path now has its own branch for it, right before the BadRequest one, and says what a full context window means. It reuses the wording the 400 path already uses, so no new translations are needed. The embedding path already classified 413 correctly in ClassifyEmbeddingRequestFailure. The two classifications stay apart on purpose, as the comment there explains, so only the chat path was extended.

Not tested against a live provider: this needs a counterpart that actually answers 413, which I could not set up. The change is confined to one new status code branch that mirrors its neighbours.