(core) Redesign the admin/setup Authentication and Sandboxing sections

Summary:
The Authentication and Sandboxing sections are now option-card choosers, built on one shared card
kit that looks like BackupsSection. Both sections appear in two places: the setup wizard and the
admin panel. In the wizard the server starts with no auth and no sandboxing, so the section shows a
recommendation first, and Continue stays disabled until something is picked. In the admin panel
the section shows what the server is really doing now, and does not pre-select anything. Applying
uses the existing pending-changes and restart flow.

Authentication now has one big "hero" card on top and the other methods below it. OIDC and SAML need
a Full Grist activation key before this UI can turn them on, so their cards show a "Requires
activation key" chip. Clicking such a card opens a modal that starts a key request (the Installation
ID is filled in), shows where to enter the key later (Admin Panel > Edition), and suggests a
sign-in method to use in the meantime. Servers that already run OIDC or SAML are not affected: the
code that picks the login system at boot did not change, so such a provider stays active. It is only
marked as "Missing activation key" with a warning. Every staged hero card also has a "Revert"
button, which drops the selection and any drafts made during this visit, the same as reloading the
page. Switching to "No auth" now always asks for confirmation first.

Sandboxing now keeps the flavor the user picked, including "No sandboxing". Before, the step opened
with the recommended flavor already selected, and "Apply and Continue" switched to it even if the
user never touched anything. Now the change is applied only if the selection asks for it, and the
recommendation is pre-selected only on a fresh install where nothing was chosen yet. "No sandboxing"
is drawn as a muted last-resort card, like no-auth in Authentication. The same section is now also
used in the Sandboxing row of the admin panel, where it shows the current state and can change the
flavor through the usual pending-changes flow.

When the admin changes the auth method, all sessions are cleared on the next restart, because logins
made with the old provider cannot be trusted any more. This also removed the admin's own session, so
an admin who set up auth for the first time was sent back to /boot in the middle of the wizard. A
session created with a boot key is now kept. Removing it protects nothing: it does not come from the
provider that is being replaced, and the same key can be used to sign in again right away.
The session store can only be cleared as a whole, so `clearAllSessions` takes the one session that
should stay and restores it after the clear.

Going live ends the setup, and after that no session is kept. The admin then has to sign in with the
provider they just configured, and finds out immediately if it works. This signs out all users, not
only the admin. After a restart the wizard now asks the server whether the session is still an
install admin, instead of assuming it is gone, and redirects to sign-in only when it is not. That
also covers the case where the admin email was changed, so the kept session no longer belongs to the
admin.

Clearing sessions never worked with Redis. connect-redis 3.4.0 has no `clear` method, so every clear
failed, with the error only written to the log. This affected any install using Redis for sessions;
in particular, SaaS build, where the auth provider cannot be changed, but that build is also used to
test ext code. connect-redis is updated to 6.1.3, and clearing an empty store no longer fails.

Additional fixes:

The installation ID is no longer sent to users who are not install admins. If admin status cannot be
decided, the ID is withheld rather than the page failing, so /admin and /boot keep working when the
home DB does not answer.

`server.restart()` in the nbrowser test helper takes a new `restartShell` option, so a test can get
a server that really restarts on /api/admin/restart instead of answering 409.

Test Plan: Updated

Reviewers: dsagal, georgegevoian

Reviewed By: dsagal

Differential Revision: https://phab.getgrist.com/D5023