APP: SSG web build never registers router guards or marks app ready

[MrDirkelz]

The web entry never registers the router guards.

app/src/main.web.ts:14 imports only ./router/routes and passes the raw route table to ViteSSG, which constructs its own router. The beforeEach guard in app/src/router/index.ts:32 is registered as an import side effect of that module, which the web entry never imports — so it never runs in the web build.

No symptom has been observed

Filing this as latent rather than active. Each consequence is currently invisible:

1. Render state pinned to loading. markAppReady() is called only at main.ts:172, and renderState.ts:11 returns "loading" while appReady is false, so data-render-state never leaves loading in dist-web/. Invisible to users — the splash screen is driven separately by isAppLoading (main.web.ts:114). Only matters if external tooling waits on the contract in app/README.md:99-120; vite-ssg renders in Node and doesn't consume it, so this may now be vestigial for the web tier.
2. The Telegram in-app-browser interstitial cannot fire in the web build, since the guard holding that redirect isn't registered. Masked until now because the UA detection in isTelegramBrowser() was itself broken (fixed in APP: InAppBrowserCheck not working with new telegram #1860).
3. markPageLoading() never runs on client-side navigation there — same cause, only observable via (1).

Scope (confirmed)

The public web tier is crawler-facing — roughly 90% of dist-web/ traffic is crawlers rather than users. That settles the question this ticket first left open:

• (1) is moot for crawlers: vite-ssg emits complete static HTML in Node, so nothing needs to wait on data-render-state.
• (2) is near-moot: an interstitial is meaningless to a crawler, and Telegram deep links land on the SPA (main.ts), which registers the guard — so the APP: InAppBrowserCheck not working with new telegram #1860 detection fix does reach real users.

Keeping this open as a correctness/consistency cleanup at lowest priority, not a user-facing defect.

Suggested fix

Extract guard registration into a function taking a Router, call it from both main.ts and main.web.ts's setup callback (which already receives router at line 49), and call markAppReady() on the web build's client branch. Touches the SSG boot path, so worth doing deliberately.

Nearby dead code (unrelated to the above)

• getRouteHistory() (router/index.ts:55) has no non-test consumers.
• markInternalNavigation() is never called in production, so isExternalNavigation() is effectively always true.