[Discussion] Replace client-side analytics init with Zaraz

Zaraz would simplify tracking invocation and management. It could also improve client-side performance, and tracking data availability. On the other hand, it could ignore or disregard visitors "do not track" preference.

I think that the main argument for adopting it is that it abstracts away the script specifics. `bati` could keep calling `zaraz.track`, and those events would be sent to the Vike site analytics automatically (once Zaraz was set up for the Vike site).

The alternative would be for `bati` to expose a callback prop run on `copy` events. Then, `docpress` (and the site-specific docpress config) would be the source of truth for analytics.

Personally, I'm on the fence. I see the convenience, but the callback alternative seems totally fine. If we really care about proxying the scripts, we can also do it through a standalone worker.

Related questions are A) migrating Bati analytics to Vike, and whether to switch the Vike site to Umami : https://github.com/vikejs/bati/issues/702

What do y'all think? @brillout @magne4000 @richard-unterberg

Given everything that's going on, I think it's fair to expect an increase in traffic. I think it would be really impactful to get the Bati analytics added to Vike as soon as possible.

Start by reviewing the proposed Zaraz approach, the callback alternative, and the related Bati issue #702. Done requires an agreed analytics direction and a defined migration scope; the discussion currently does not identify files, tests, or a decided implementation.

Written by the indexing model from the issue text.