Handle a wishlist that can no longer be shown while its page is open

[boo-code]

Questions	Answers
Description?	The products resolver in _dev/front/js/graphql/resolvers.js reads datas.pagination.total_items straight off the response body with no check on the response. BlockWishlistViewModuleFrontController redirects whenever the list cannot be shown — to the 404 controller once it has been deleted, to the home page once it is no longer readable by this visitor — and fetch follows both, so the body is a 404 payload or a home page rather than the product payload. Reading pagination off either throws, which is the console error in the report, and the page carries on describing a list that no longer exists. A redirected response now sends the browser to the request again so the shop renders whichever page it meant to; any other unexpected response returns an empty result instead of throwing.
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes PrestaShop/PrestaShop#28837
How to test?	Sign in on the front office, create a list, add products, open it, then delete that list from a second tab. Back in the first tab, click sort by. Before the change the console throws on pagination and the page keeps showing the deleted list; after it, the browser lands on the shop's 404. Same with a shared list whose sharing is revoked, which lands on the home page with the module's own notification.

Measured, module 4.0.0 on PrestaShop 9.2

Two different redirects, which is why one guard is not enough. fetch follows both, so response.status
below is the status of the redirect target:

list deleted / id unknown     302 -> /?controller=404   final 404  application/json
                                                        body "The page you are looking for was not found."
list exists, no read access   302 -> /                  final 200  text/html
valid request                 200  application/json     body has products, pagination, sort_orders, ...

The second case is the one that makes a !response.ok test insufficient: it ends on a 200, so only
response.redirected distinguishes it from a normal answer. Both cases are covered by the single
response.redirected branch; the !response.ok and JSON-parse guards below it exist so that a server error
does not throw either, without navigating away — a reload on any failure would loop against a persistent 500.

The valid payload always carries pagination (current_page, items_shown_from, items_shown_to,
pages, pages_count, should_be_displayed, total_items), so !datas.pagination is a sound
"this is not our payload" test.

The bundle is deliberately not in this branch

public/*.bundle.js is tracked, and the module loads public/productslist.bundle.js at runtime, so this
change does nothing until the bundle is rebuilt. It is not rebuilt here because the committed bundles do
not reproduce from the committed sources: npm ci && npm run build on dev produces a 14-file, 640-line
diff before any source change, byte-identical on Node 20 (the version
.github/workflows/build-release.yml uses) and on Node 24, so it is source drift rather than toolchain
noise. Part of it is the license banner the build does not emit — restoring that by hand fixed only 4 of the
14 files. Committing a rebuild here would bury a small fix inside somebody else's unbuilt change, so the
branch carries the source only.

Fixture note

The first measurement of this was wrong. ps_module had active = 0 and no ps_module_shop row, and
in that state every request to the module's front controller returns a bare 404 application/json — which
looked like the real answer and hid the two distinct redirects. Enabling the module for the shop
(INSERT INTO ps_module_shop) is what exposed them. A module front controller measurement is only valid
once the module is associated with the shop.