404-Seite cached Login-Status und verursacht falsche Sichtbarkeiten (Shopware 6.6)

### Shopware Version

6.6.10.4

### Affected area / extension

Platform(Default)

### Actual behaviour

Shopware 6.6.x (confirmed in 6.6.10.4)
Not reproducible in 6.7.x (after cache rework)

The 404 page currently caches the user-specific login status. This means that logged-in or logged-out statuses are passed on to subsequent users via the cache.

This results in incorrect navigation, access, and visibility statuses being delivered.

The behavior was reproduced internally and confirmed by Tobias Kaßner (including video).

Actual behavior
- Login status (logged in/logged out) is cached
- This status is transferred to other users

Translated with [DeepL.com](https://www.deepl.com/?utm_campaign=product&utm_source=web_translator&utm_medium=web&utm_content=copy_free_translation) (free version)

### Expected behaviour

- The 404 page must not cache any user-specific status
- No incorrect login, access, or visibility statuses may be delivered

### How to reproduce

Scenario A – logged-in user first

Log in as a customer.
- Call up a non-existent URL (404 page).
- Log out.
- Call up the same 404 page in a new session/different browser.

Result:
- Customer navigation is displayed.
- Categories hidden by dynamic access rules remain visible.

---

Scenario B – logged-out user first

Call up a non-existent URL as a logged-out user
- Log in as a customer
- Call up the same 404 page again

Result:
- The user appears logged out
- Blocked categories remain hidden even though the user is logged in

Translated with [DeepL.com](https://www.deepl.com/?utm_campaign=product&utm_source=web_translator&utm_medium=web&utm_content=copy_free_translation) (free version)

Start by reproducing the 404-page behavior in Shopware 6.6.10.4 using both logged-in-first and logged-out-first scenarios, then trace how the 404 response is cached and how login, access, and visibility state enters it. Done means repeated requests from different sessions never receive another user's status, while the reported visibility behavior remains correct.

Written by the indexing model from the issue text.