[BUGFIX] facet URL encoding mismatch (spaces) when using urlParameterStyle=assoc

  ## Problem

  When using `faceting.urlParameterStyle = assoc`, facet links containing spaces
  in their values are rendered with an unresolved placeholder instead of the
  actual filter value:

  ?tx_solr[filter][materials:Material 1]=###tx_solr:filter:materials:Material 1###

  Values without spaces work correctly:

  ?tx_solr[filter][materials:Baustähle]=1

  ## Root Cause

  In `SearchUriBuilder::buildLinkWithInMemoryCache()`, the placeholder keys for
  `str_replace` are computed using `urlencode()`, which encodes spaces as `+`.
  However, TYPO3's `UriBuilder` builds the URL template using `rawurlencode()`
  (RFC 3986), which encodes spaces as `%20`.

  The `str_replace` silently fails to find the `+`-encoded key in the
  `%20`-encoded template, leaving the raw `###...###` placeholder in the output.

  ## Fix

  Replace `urlencode()` with `rawurlencode()` in the second `$keys` computation
  (the one used for the actual `str_replace` against the URL template). This
  aligns the encoding with what TYPO3's `UriBuilder` produces.

  The first `$keys` block (passed to `BeforeCachedVariablesAreProcessedEvent`)
  is intentionally left unchanged to avoid side effects on existing event
  listeners.

  ## Affected versions

  Reproduced on EXT:solr 13.1.1 / TYPO3 13.4 with `urlParameterStyle = assoc`.

---

- Use rawurlencode (spaces → %20) to match TYPO3's UriBuilder encoding.
- urlencode encodes spaces as "+" which does not match "%20" in the URL template.

Ports: #4610

Author: dkd-hauser

Classes/Domain/Search/Uri/SearchUriBuilder.php

@@ -337,7 +337,7 @@ protected function buildLinkWithInMemoryCache(?int $pageUid, array $arguments):
             if (!str_contains($value, '###')) {
                 return $value;
             }
-            return urlencode($value);
+            return rawurlencode($value);
         }, array_keys($values));
 
         $uri = str_replace($keys, $values, $uriCacheTemplate);