Authorization Code + PKCE flow returns invalid_grant despite verified-correct client config and a fresh code

[Frank78]

Setup:
- Client type: public client, PKCE required (confirmed — see below), no client secret
- redirect_uri: http://localhost:4200/ (registered exactly as such in the developer portal, verified via the client editor UI)
- Scope requested: IoT User offline_access
- Grant: authorization_code with code_challenge_method=S256

Flow followed (per the Getting Started guide):
1. GET https://iam.viessmann-climatesolutions.com/idp/v3/authorize?client_id=...&redirect_uri=http://localh......
2. Logged in interactively in a real browser (reCAPTCHA passed normally).
3. Browser redirects to http://localhost:4200/?code=...&state=... as expected — state always matches.
4. POST https://iam.viessmann-climatesolutions.com/idp/v3/token with grant_type=authorization_code, client_id, redirect_uri, code, code_verifier.

Result every time: 400 {"error":"invalid_grant","error_description":"Invalid grant"}

What I've ruled out, to save the next reader's time:
- PKCE math — independently recomputed BASE6and confirmed it matches the code_challengesent at step 1. - Code freshness / latency — set up a local irect URI that performs the token exchangeinline, in the same process, the instant the redirect lands (effectively zero delay between code issua exchange). Same invalid_grant.
- Client/redirect_uri mismatch — visually confirmed in the developer portal's client editor that the reg redirect URI is exactly http://localhost:4n both requests, and this was alreadyconfigured before any of these attempts (not something added reactively). - PKCE optionality — tried omitting code_cha entirely to see if this client accepts aplain authorization_code flow. Got a different, earlier error instead: invalid_request: "Code Challeng thrown at the /authorize step itself, befored. This confirms PKCE is mandatory for thisclient and that the client is otherwise reachable/valid. - Tested across 5 independent attempts with ier each time — same result every time.
Additional context: the same client_id can sccess token via the developer portal's own"try it" feature, and that token works fine against the IoT API. So the client itself is active and the client_id/scope combination is valid for APIthe browser-driven Authorization Code + PKCEexchange that fails.