check sandbox viability lazily (#1226)

This checks whether code can successfully run in the
sandbox only when the admin panel needs to report that,
rather than at start up. This is motivated by two things:

  - The desktop app became a lot slower to open with this
    check, since it uses pyodide by default, and there's
    been no work on optimizing the pyodide sandbox load
    times (as opposed to gvisor, where a lot of work was
    done, and it is also fundamentally faster).
  - The messages logged by a test sandbox starting and
    stopping have been confusing people.

There is a case for doing the check on startup, especially
on servers, so that we can fail early. Still, that isn't
what we were doing, and we'd also like to move away from the
server refusing to start because of a problem and
towards an always-reachable admin page that reports
the nature of problems in a clearer way.

app/client/ui/AdminPanel.ts

@@ -202,7 +202,10 @@ Please log in as an administrator.`)),
         const success = result?.status === 'success';
         const details = result?.details as SandboxingBootProbeDetails|undefined;
         if (!details) {
-          return cssValueLabel(t('unknown'));
+          // Sandbox details get filled out relatively slowly if
+          // this is first time on admin panel. So show "checking"
+          // if we don't have a reported status yet.
+          return cssValueLabel(result?.status ? t('unknown') : t('checking'));
         }
         const flavor = details.flavor;
         const configured = details.configured;