feat: implement startup splash screen and loading behavior

[ChrisTouo]

The splash lived in App.vue, so it could not appear until app.mount() — the
second-to-last step of Startup(). Everything slow (Dexie open, schema upgrades,
OIDC setup) ran before that against an empty #app, and the only work left after
it was initLanguage(), a local IndexedDB read on a warm cache. That can resolve
within a single animation frame, so the splash often never painted at all, while
the part of the boot that actually takes time showed a blank page.

Mounting earlier is not an option. app.use(router) starts the router's initial
navigation, and isNotAuthenticatedGuard gates on isAuthPluginInstalled, which
only setupAuth() sets — running the guard first makes a logged-in user look
logged out on a cold load.

So the splash moves out of Vue. index.html carries it as plain HTML/CSS and
paints it on first parse, with a pre-paint script that resolves the theme the way
globalConfig does (darkMode is "class", so nothing sets that class until the
first module runs). It uses /logo.svg from public/ rather than VITE_LOGO, whose
configured value is page-relative and 404s below the root. main.ts removes it
once startup finishes, after a nextTick so the app is already painted underneath
and uncovering cannot expose a blank frame.

The web/SSG build strips it in the existing rewriteWebEntry transform: that build
ships already-rendered HTML with no blank window to cover, and it boots
main.web.ts instead of main.ts, so nothing there would ever remove the overlay.

With index.html owning the splash, App.vue's copy sat under an opaque overlay for
every frame it existed, so it is removed; isAppLoading still gates the app
content, the KeepAlive and the modals.

[johan-bell]

Verified this hands-on — the core is excellent: the pre-paint theme script exactly mirrors globalConfig's resolution (dark / light / else system + matchMedia), /logo.svg exists in public/ so the root-absolute path works at any route depth, the strip in rewriteWebEntry is correct, and bootSplash.spec.ts tying the three drift-prone pieces together is a really nice touch. Three things before it can go in:

• Error path: Startup().catch calls markAppError() but never removes the splash, and the splash has no error state — a failed boot now shows an infinitely animating progress bar. The catch should swap the splash to an error message (or at least remove it). #1972 solves this with a data-render-state="error" panel + Reload button worth borrowing.
• ?nosplash regression: isAppLoading honours it but the static splash doesn't, so consumers of the opt-out now get a splash that stays up until startup finishes. A one-line guard in the pre-paint script fixes it.
• Collision with #1972: that PR also injects a static boot splash (inside #app, via a Vite plugin, with error/reload, nosplash and prefers-reduced-motion handling). Both cannot merge as-is — please converge on one implementation with Dirk. This PR's placement (outside #app, removed after full startup with the nextTick trick) covers the boot more completely; #1972's error panel and opt-outs are the missing half.

Minor: the hardcoded English "Loading..." is new user-visible text (the old splash was logo-only), and deployments configuring VITE_LOGO will show the default logo during boot.

[ivanslabbert]

Remove the "Loading..." text and make sure the graphics is intuitive enough to indicate to the user that the app is loading

[ivanslabbert]

Check why timers are used as guardrails. There must be a better way to detect when indexedDb is unblocked

[ChrisTouo]

Why the change in database.ts

A deploy that changes the docs index bumps the IndexedDB version. IndexedDB can't apply that upgrade while other tabs still hold the old version open, so the browser fires versionchange on those tabs and blocks the upgrading one.

Dexie already handles this by closing the old connection so the upgrade can proceed, and we keep that — holding on would block the other tab indefinitely. What we add is what happens next: a background tab just closes and reopens lazily, but a visible tab is running code built for the old schema, so it reloads onto the new version instead of carrying on against a database it can no longer use.

Separately, blocked is no longer treated as an error. It means "waiting for another connection to close," which resolves on its own, so the boot waits instead of failing.