Translatable collection responses omit the Accept-Language cache context when no language selector is present, poisoning later negotiated reads

Problem/Motivation

EntityResource::getCollection() only declares the language cache context when the request already carries a language selector (?langCode= or an Accept-Language header). A collection GET with no selector therefore produces a response that does not declare it varies by Accept-Language.

Steps to reproduce

1. A translatable content type with two nodes, e.g. Alpha (default en, plus a fr translation) and Beta (default fi, no fr).
2. Uninstall the Internal Page Cache to isolate this from #2430335: Browser language detection is not cache aware.
3. GET /jsonapi/ with no language selector → 200, each item in its default language (Alpha (en), Beta (fi)). This warms the Dynamic Page Cache.
4. GET /jsonapi/ with Accept-Language: fr.
5. Expected: the per-item negotiated result (with the strict-negotiation branch, Alpha in fr and Beta excluded; with per-item fallback, Alpha in fr, Beta in its default).
6. Actual: the cached step-3 normalization — Alpha (en), Beta (fi) — because the cached response did not vary by Accept-Language.
7. Reverse the order (step 4 before step 3, on a cold URL) and it works, confirming the order dependency.

Proposed resolution