Make identity-provider sign-in work with the registered client

[rbardaji]

Closes #219.

The installer offered sign-in through the identity provider, then asked for a client id with no default and no way of finding one:

  Offer sign-in through the identity provider? [y/N]: y
  Identity provider realm URL [https://idp.nationaldataplatform.org/realms/NDP]:
  Client id registered for this Endpoint:

A blank answer switched sign-in back off with a warning, so the feature was offered and could not be taken.

What changed

Endpoints in the NDP realm do not each need their own client — the platform's public client serves any of them, in the realm the installer already suggests as the issuer. Both are defaults now:

  Client id [ndp_frontend_prod]:

Answering yes and pressing Enter is enough. A client id registered for this Endpoint specifically — a Federation registration creates one and prints it — can be given instead.

--oidc, --oidc-issuer and --oidc-client-id are new. The identity-provider questions were the only prompts with no flag behind them, so an unattended install could not enable sign-in at all, contrary to what install/README.md claims.

A registration still never switches sign-in on by itself: --config-id skips every prompt, so there is nobody to ask, and enabling a login method for an operator who did not request it is not the installer's call. It now says how to enable it instead of only saying it is off.

Verified

• Interactive run driven through a pty: Client id [ndp_frontend_prod]: accepted with Enter, .env gets OIDC_ENABLED=True with both defaults.
• --oidc alone, and --oidc-client-id <other>, render the expected values; without any of them OIDC_ENABLED=False, unchanged.
• The container started with that .env serves the UI a config.js carrying oidcEnabled, oidcIssuer and oidcClientId, and the realm's discovery document advertises S256, which is what the UI's PKCE flow needs.
• 1204 tests pass, black --check . and flake8 clean.

While wiring the defaults, an unguarded reference to a variable that does not exist yet at the prompt would have aborted the script under set -u the moment anyone answered yes; it is not in the branch.

[rbardaji]

Parking this. Identity-provider sign-in is not going into the installer until how it is meant to work is settled, so the option should not be offered at all in the meantime.

What this branch established, for whoever picks it up:

• Every client in the NDP realm is confidential, including the one a Federation registration creates per Endpoint (publicClient: False, client-secret authenticator). A browser-side code exchange can therefore only ever answer unauthorized_client / "Invalid client or Invalid client credentials".
• Exchanging the code on the Endpoint instead does work: with the registered client and its secret, the token endpoint answers invalid_grant ("Code not valid") for a fake code, i.e. the client authenticates.
• It still fails one step later. Tokens minted for these clients carry no sub claim, and AUTH_API_URL looks the user up by sub, so it answers 500 {"error":"Failed to retrieve user details","details":"Role query failed"} — surfaced to the user as a 502 from /user/info. A token from the same client's service account does carry sub and validates fine, which is the contrast that isolates it.
• The cause is the client factory in the AAI: defaultClientScopes: ["profile", "roles", "email"], without basic, which is where sub comes from since Keycloak 24. It cannot be worked around from the Endpoint — requesting the scope answers invalid_scope: basic, since it is assigned to the client neither by default nor optionally.

So this needs basic assigned to those clients (or added to the factory) before any of it can work end to end. The branch feature/219-oidc-default-client is kept.

The one commit here that is independent of all that — the installer reusing a stale image — is now #222.