When "/reload/" paths are not enabled for SSR, sometimes i18n language pack fails to load

[tdonohue]

Describe the bug

This issue is related to #3682.

In my local development environment, I've encountered a scenario where after authenticating, sometimes SSR briefly turns off and then back on again. When SSR turns off, this can result in language packs not loading properly. Strangely, I cannot seem to reproduce this on sandbox.dspace.org, but the behavior is consistent in my local environment.

Here's what I'm doing:

1. Running latest main code as of Jan 31 for both frontend & backend
2. Starting frontend in Production mode: npm run build:prod; npm run serve:ssr
3. Visiting the homepage
4. Immediately logging in as any user

After login, in the logs for server-side rendering (where you ran npm run serve:ssr), I'm seeing this when the login occurs:

Universal off, serving for direct client-side rendering (CSR)
GET /reload/1738353823478 200 1.632 ms - 751
GET /home 200 947.703 ms - -

(The message "Universal off" is only triggered when SSR is disabled while the "server.ts" code is run)

After login, the homepage will load up without any i18n translations. Here's an example of what the header looks like:

The issue appears to be with the ssr.paths setting. It MUST include the /reload/ path (which is triggered after login to perform a hard refresh). When /reload/ is added to the configuration, I no longer see this odd behavior.

ssr:
  paths: [ '/home', '/items/', '/entities/', '/collections/', '/communities/', '/bitstream/', '/bitstreams/', '/handle/', '/reload/' ]

I'll submit a PR to all three branches shortly to fix this issue.

Related work

Related to #3682