Mighty Max 0.3.2 — server-terminated connection retries

Covers 0.3.1 + 0.3.2 (0.3.1 was version-bumped but never released).

Fixed

Server-terminated connections (TypeError: terminated) are now retried

When the MiniMax server closes the socket mid-request — observed on a large (352-message) request, surfacing as MiniMax API error (network): terminated with zero retries — the failure now engages the transport's retry machinery:

• isRetriableNetworkError walks the error's cause chain, so undici's TypeError: terminated / fetch failed wrappers (which carry the socket-level ECONNRESET / UND_ERR_SOCKET code on .cause, never on the thrown error itself) are recognized as transient. Bare terminated errors with no cause are matched by message.
• The SSE parsers mark mid-stream network failures retriable, so a body that errors before delivering any event is re-issued transparently by the before-first-event retry driver. Post-first-event terminations still surface immediately (a retry would duplicate delivered content).
• The chat error for network failures now explains that the connection dropped and safe retries were exhausted, instead of the bare envelope.

Four-test regression suite in transport.test.ts ("server-terminated connections").

Deprecated managementCommand replaced with the new configuration schema

VS Code 1.109+ flags contributes.languageModelChatProviders[*].managementCommand as deprecated. The provider entry now uses the new configuration.properties block with apiKey as a secret: true string setting (routed through SecretStorage). The mightyMax.manage command remains registered and is still the authoritative write path for the API key.

Full changelog: https://github.com/greysquirr3l/mightymax-vscode/blob/main/CHANGELOG.md