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

[Frank78]

MS-R06 is active and working on live data — confirmed via the earlier successful test run.
- The invalid_grant mystery remains unresolved. Every check I can perform from outside says the request should work: client_id and redirect_uri match exactly (confirmed via your portal screenshot), 

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 BASE64URL(SHA256(code_verifier)) and confirmed it matches the code_challenge sent at step 1.
- Code freshness / latency — set up a local loopback listener on the redirect URI that performs the token exchange inline, in the same process, the instant the redirect lands (effectively zero delay between code issuance and exchange). Same invalid_grant.
- Client/redirect_uri mismatch — visually confirmed in the developer portal's client editor that the registered redirect URI is exactly http://localhost:4200/, matching what's sent in both requests, and this was already configured before any of these attempts (not something added reactively).
- PKCE optionality — tried omitting code_challenge/code_challenge_method entirely to see if this client accepts a plain authorization_code flow. Got a different, earlier error instead: invalid_request: "Code Challenge Required", thrown at the /authorize step itself, before the login page even rendered. This confirms PKCE is mandatory for this client and that the client is otherwise reachable/valid.
- Tested across 5 independent attempts with fresh state/nonce/code_verifier each time — same result every time.

Additional context: the same client_id can successfully mint a working access 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 API access — it's specifically the browser-driven Authorization Code + PKCE exchange that fails.