fix: restore status page custom domains

[anjupathak03]

Describe your changes

Restores custom-domain status page routing when CLIENT_CONFIG_CLIENT_HOST is not explicitly configured.

The runtime-config migration omitted clientHost from /config.js by default. On a custom domain, the client therefore fell back to that domain's own window.location.origin, treated it as the main Checkmate host, and rendered the login routes instead of resolving the published status page.

This change:

• always exposes the canonical CLIENT_HOST through the generated client config
• preserves CLIENT_CONFIG_CLIENT_HOST as the explicit higher-priority override
• adds regression coverage for fallback and override behavior
• updates configuration comments and README guidance to describe the actual precedence

Write your issue number after "Fixes "

Fixes #3811

Verification

• Deployed locally and verified that the custom-domain status page resolves correctly when CLIENT_CONFIG_CLIENT_HOST is not configured.
• npm test -- --runTestsByPath test/unit/services/settingsService.test.ts --runInBand --coverage=false — 13 tests passed
• npm test -- --runInBand --coverage=false — 74 suites, 1,328 tests passed
• npm run typeCheck in server
• npm run lint in server
• npm run build in server and client
• npm run format-check in server and client
• git diff --check

Checklist

• I deployed the application locally and verified custom-domain status-page routing.
• I have performed a self-review and tested the change.
• I have included the issue number.
• i18n is not applicable because no visible strings were added.
• I have not included unrelated files or dependency changes.
• No production values or styles are hardcoded.
• Theme requirements are not applicable because there is no UI styling change.
• The PR is granular and targeted to one regression.
• Formatting was verified in both server and client.
• A screenshot is not applicable because the change restores routing/configuration behavior without changing the UI.

[anjupathak03]

Custom-domain verification is complete. I confirmed that the published status page resolves correctly when CLIENT_CONFIG_CLIENT_HOST is not configured. The PR description and checklist have been updated, and this is ready for maintainer review.

[m3nu]

The CLIENT_HOST fallback is the right fix for #3811, but it also makes isCustomDomainHost() live for the first time on every deployment, and the branch it gates is broader than the bug being fixed.

Routes/index.tsx:60 replaces the entire route table with <Status/> on a hostname mismatch alone — before anything has checked whether a status page actually exists for that host. So any instance reachable at more than one hostname loses the app on the secondary one: www vs apex, or a platform-provided default URL that stays reachable next to a custom domain.

The failure mode is a blank page rather than an error. Status/index.tsx:104 returns null when /status-page/resolve?domain=… finds nothing, and that sits above the loading and empty-state branches, so every route on that hostname renders an empty document. It reads as an outage, not a misconfiguration.

There's also no way to opt out once this merges: clientHost is now always populated, so no combination of CLIENT_HOST / CLIENT_CONFIG_CLIENT_HOST restores the current behaviour.

Would it work to gate the status-page routes on the resolve actually returning a status page, and fall back to the normal route table when it doesn't? That keeps #3811 fixed for genuine custom domains, and turns the unknown-host case into the normal app instead of a blank screen.

Context: we host Checkmate for users at PikaPods, where each instance keeps its default *.pikapod.net hostname alongside any custom domain — so this would affect every instance with a custom domain configured.