Query string loss during cached trailing slash redirects when using CacheKeyModify

Hi,

when using the "Drop Query String" feature (e.g., -qs:utm_source or -qs:gclid), the LiteSpeed Cache engine strips these parameters to find a cache match. If the requested URL (without a trailing slash) triggers a WordPress redirect to the version with a trailing slash, the cached redirect might be different from the url the user requested.
I think by default, this is the case for
fbclid, gclid, utm*, _ga

Steps to Reproduce:

• Add Drop Query String test_param
  Visit example.com/page (no slash, no param). WordPress redirects to domain.com/page/. LiteSpeed caches this redirect.
• Visit domain.com/page?test_param=123.
  Observed Result: LiteSpeed matches the cached redirect for /page and sends the user to domain.com/page/. The ?test_param=123 is lost.
  Expected Result: The user should be redirected to domain.com/page/?test_param=123.

Environment:

Plugin: LiteSpeed Cache for WordPress
Server: OpenLiteSpeed
Feature: Drop Query String / CacheKeyModify

No file or test is named in the issue. Start by reproducing the CacheKeyModify scenario with a dropped test_param, then trace the cached trailing-slash redirect handling. Done means the redirect preserves the query parameter and the reproduction steps pass without losing it.