I forgot to say - with a Linux client, using git-credential-oauth, everything works as expected with this remote, so the Apache setup with mod_oauth2 and Keycloak is known to work. The .gitconfig is:

[credential "https://example.com"]
  helper            = cache --timeout 7200
  helper            = "oauth -verbose"
  oauthClientId     = openid-cli
  oauthScopes       = "openid email"
  oauthAuthURL      = ...as before
  oauthTokenURL     = ...as before
  oauthRedirectUri  = http://127.0.0.1
  oauthClientSecret = ...as before

[user]
  name  = ...
  email = ...

Normal OAuth flow: request grant stuff → refresh_token → access_token

An access_token (the thing Git can work with) has a short lifetime and a new one must be requested after a short while.
While refresh_token (might) also expire, they can (optionally) be rotated on each access_token request.

The following is based on the observed effects and my pure speculation on the cause…

While the initial access_token is valid, Git operations can happen normally.
After it expires, a valid refresh_token must be used to request a new one.

There is currently a bug in GCM (#1838) not saving an inline refresh_token update for access_token response.
So in case your server enforces strict Refresh token rotation this invalidates the OAuth data on the next request.

You might have gotten away with deleting (aka. changing the value of) the oauthClientSecret after the initial setup.
But it seems if there is any need to get a new initial refresh_token, the mismatch is detected and the client is rejected.

So in summary:

• do not change/touch the oauthClientSecret, the refresh_token may also expire by itself at some point
• make sure all clients are distinctly identifiable by the server, so their token rotations do not clash
• hope the fix for refresh_token rotation will ship in a timely manner.

With fixes for token related issues (#1838 and #1837), the OAuth flow with our local Forgejo instance works flawlessly. ☺