Liferay: add cookie + HTML signals for response-first detection

[danielserranoh]

Liferay matches only the Liferay-Portal response header and the window.Liferay JS global. Hardened / CDN-fronted installs strip the Liferay-Portal header, and response-first (non-headless) analysis can't observe window.Liferay, so Liferay goes undetected despite unmistakable static markers.

This adds unique static signals (keeping the existing header/JS matches and version capture):

• html: Liferay\.(?:Util|Language|ThemeDisplay|AUI) (Liferay client JS API namespaces) and id="_com_liferay_ (portlet DOM id prefix).
• cookies: GUEST_LANGUAGE_ID; COOKIE_SUPPORT at confidence:50 (generic name, not standalone).

---

Test websites:

• https://www.javeriana.edu.co/
• https://www.um.es/
• https://www.ehu.eus/

Assisted by Claude Code.

[danielserranoh]

Closing this one. Per the discussion in #352: html is deprecated and slower, and HTTP Archive runs Wappalyzer with DOM detection — where the existing Liferay-Portal header and window.Liferay matches already fire. My motivation was response-first detection in an internal engine that can't evaluate dom, which is out of scope here, so I'll carry these signals locally instead.

One note in case it's ever useful: the cookies half of this PR (GUEST_LANGUAGE_ID, plus COOKIE_SUPPORT at lower confidence) isn't affected by the html concern and does help on hardened/CDN-fronted installs that strip the Liferay-Portal header — javeriana.edu.co is one. Happy to open a cookies-only PR if that's of interest; otherwise no need to reopen.

Thanks for the review.