fix(SingleContent): ensure correct content rendering on slug change and add navigation tests

[MrDirkelz]

No description provided.

[johan-bell]

Solid fix — scoping every read of the slug query's window to the current slug closes the stale-render path cleanly, and the added tests fail on main. Non-blocking notes: the comments at SingleContent.vue:199/288 still describe the old contentArr semantics and read stale next to contentForSlug; keying the player on content._id also rebuilds it on an in-place translation switch (no carried-over position) — flagging in case that UX wasn't intended; and with the slug scoping in place, cache:true on the slug query is effectively write-only for the non-SSG SPA, so it could be scoped to isSSG.

[ivanslabbert]

We need to find the issue at source (in how HybridQuery is used). It seems as if some type of response caching is enabled, causing the query to give old values before mutating to the correct value.

[MrDirkelz]

You were right, it's fixed at source now.

Two things were keeping the previous post on screen. The response cache — its key is a structural fingerprint that excludes values, so with a per-slug cacheId only on the SSG build, every article shared one entry. And _rebuild, which deliberately keeps output across a rebuild; that one has nothing to do with caching, which is why scoping the cache alone still left the in-app navigation flash.

The keep-across-rebuild can't be inferred from the selector — a feed switching category wants the old tiles held as a placeholder, a slug lookup switching article doesn't, and the two look identical from inside HybridQuery. So it's a declared option now: keepPreviousResult, default true so no existing consumer changes. Both queries here set it false, plus cache: isSSG.

That let contentForSlug and the availableTranslations filter come back out. Only the VideoPlayer :key stays — the translation switch swaps content directly without rebuilding a query.

edee0ec3