Refuse an OIDC sign-in from creating the very first user

Closes the race terdut-operator#1 found: /api/bootstrap and OIDC
auto-provisioning both key off the same signal (SELECT COUNT(*) FROM
users) with no coordination between them, so an otherwise-ordinary OIDC
sign-in against a freshly-created, not-yet-bootstrapped install could
create user #1 itself and take the one slot /api/bootstrap expects to win
uncontested (terdut-operator's own design, DESIGN.md §1/§6, assumes it is
the only caller). The operator has no way to recover from losing that
race -- it never gets a credential, and nothing it owns can clear the
occupying user row.

resolveSSOUser now checks the same gate handleBootstrap already does,
right where it's about to create a brand-new user (an identity nobody has
linked yet, that also matches no existing local account by email) -- not
anywhere else, since every other sign-in on an already-bootstrapped
install is unaffected. New sso_error code `not_bootstrapped`: the person
sees "this install is still setting up, try again in a moment" and a
second attempt once something has actually bootstrapped succeeds
normally, same as any other first sign-in.

Does not fix the other half of that issue (BootstrapStateLost's own
"delete and recreate" instructions still don't work once something has
occupied the slot some other way) -- this closes the specific race, not
every path to that state.

internal/web/static/js/app.js

@@ -355,6 +355,7 @@ function ssoErrorText(code, name) {
     no_email: `${sso} did not send an email address for you, which terdut needs.`,
     email_conflict: 'An account with your email address already exists and could not be linked to this sign-in. Ask an administrator.',
     disabled: 'Your account is disabled. Ask an administrator.',
+    not_bootstrapped: 'This install is still setting up. Try again in a moment.',
   }[code] || `Signing in with ${sso} failed.`;
 }