Tell a failed OIDC sign-in apart, and come back to the right address

[cerede2000]

P3-06 of phase 3 (see #373). Stacked on #433, #434, #435, #436 and #437 — merge those first and this shrinks to its own diff.
its own diff.

Which of two failures it was

A sign-in that cannot start has one of two causes: nothing was configured, or what was
configured could not be made to work. The first is answered by filling in OIDC_ISSUER
and the rest; the second is answered by looking at the provider. Both answer
404 OIDC is not configured today, so an administrator whose provider is unreachable
is sent to change a configuration that is already correct.

configureOidc now records what it concluded and why, in utils/oidcAvailability.js,
and the routes read it:

Cause	Answer
nothing configured	404 AUTH_OIDC_NOT_CONFIGURED
configured, and the provider could not be reached	503 AUTH_OIDC_PROVIDER_UNAVAILABLE

Neither carries the network's own words — no ENOTFOUND, no internal host name, in the
body or in the address bar. A browser asking for one of those addresses is looking at a
page rather than reading JSON, so it is redirected to the sign-in screen with the code
beside the sentence, and the screen can say what the code means in the reader's own
language.

Where the callback comes back to

The return address was built from a fixed baseURL, so a deployment reached through a
reverse proxy under a different name sent people back to the wrong origin. It is now
resolved from the request — but only from X-Forwarded-Host behind a proxy Express
trusts, and only when the result exactly matches an origin the operator configured. A
redirect target a request header could choose is an open redirect with extra steps.

The path is still held to a relative, same-site one, as it was.

Also here, because they are the same files

• A guest session that outlived the sign-in. The guestSession cookie was cleared
  on /api only, at five sign-in and sign-out paths, while it can also be set on /.
  Now both.
• Two local copies removed. claimsFromIdToken in the middleware does what
  utils/idToken.js already exports, and uniqueOrigins in the routes what the new
  utils/oidcRedirect.js does — and the shared one normalises each value to an origin
  rather than only trimming it.
• ServiceUnavailableError (503) and the two AUTH_OIDC_* codes, which nothing had.

Deliberately not here: the account lockout that routes/auth.js also differs in.
It is a different subject — 8 of the file's 20 hunks are OIDC and those are the ones
applied — and it goes with releasing a locked account, in P3-24.

Checks

Seven test files, 107 tests, three of which this fork had and main did not:
oidc-middleware, oidcOrigin, auth-oidc-routes.

The proof they hold the change: neutralising getOidcAvailability so it reports one
verdict for both causes turns three of them red — exactly the three that tell the
two apart.

• Whole backend suite: 2 391 passed, 2 failed — auth.test.js (current password)
  and browse-hidden-files.test.js, the two that fail on main on its own.
• npm run lint: 146 against main's 143. The three are the
  'import' and 'export' may appear only with 'sourceType: module' parse error that
  141 of main's own test files already draw, because .eslintrc.cjs does not declare
  backend/tests/** as modules. P3-42 offers a fix for that.
• npm run format:check: the same 22 files as main; everything this touches is clean.
• npm run build, the backend module load and npm run docs:build all pass.

One assertion was rewritten rather than ported as it stood: it matched the wording
express-openid-connect gives a callback with no sign-in in progress, and that wording
differs between 2.19 and 2.20. It asserts the refusal now, and leaves the sentence to
the library.

The six strings the screens ask for are in all fifteen catalogues.

[cerede2000]

Correction pushed to this branch, and through the ones stacked on it.

This branch renamed what the sign-in box holds. It takes an email address or a username, so it is neither — it is whatever was typed, and the screen and the client were changed to call it identifier. The store and the route were not, so stores/auth.js passed email to a client destructuring identifier, JSON.stringify dropped the key whose value was undefined, and the request went out carrying a password and nobody to sign in.

The answer was 401 AUTH_INVALID_CREDENTIALS, which is exactly what a wrong password looks like — which is why nothing about it read as a defect. Password sign-in did not work at all on this branch as it stood.

Driven in a browser against a build of it, the body was:

{"password":"motdepasse123"}

attemptLocalLogin already took identifier; the route was what had not caught up. It now reads identifier || email || username, so a script or an older client sending either older name still works.

tests/routes/sign-in-identifier.test.js signs in with each of the three names, refuses a wrong password, and reads the three frontend files to check they all use the one name — the chain is four files long and three of them have no runner in this repository, which is how it broke silently in the middle. Putting the store back to email turns that last one red; taking identifier out of the route turns the first two red.

The fix is in this branch's commit rather than a later one, so no point in the stack is ever broken. The eleven branches stacked on it (#439–#449) were replayed on top and force-pushed; nothing else in them changed.