fix(i18n): sweep hardcoded 'en-US' from non-loyalty JS to I18n.locale

Follow-up to dd1f9af8 which fixed loyalty. The same hardcoded 'en-US'
in toLocaleDateString / toLocaleString / Intl.NumberFormat appeared in
13 files across catalog, marketplace, orders, tenancy, inventory,
monitoring, cms, the storefront layout, and the shared Utils helper
itself. After this sweep, no non-loyalty JS hardcodes 'en-US' anymore;
all use I18n.locale and respect the user's dashboard language.

The highest-leverage one is static/shared/js/utils.js (Utils.formatDate
/ Utils.formatDateTime / Utils.formatCurrency / Utils.formatNumber) —
those four helpers are called from across the frontends so this one
edit fixes most secondary callsites for free.

Codemod scope was conservative: only replaced 'en-US' when it
appeared as the first argument to toLocale* or new Intl.* calls, to
avoid touching unrelated occurrences (none found, but the guard
matters if more get added).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

app/modules/monitoring/static/admin/js/imports.js

@@ -387,7 +387,7 @@ function adminImports() {
 
             try {
                 const date = new Date(dateString);
-                return date.toLocaleString('en-US', {
+                return date.toLocaleString(I18n.locale, {
                     year: 'numeric',
                     month: 'short',
                     day: 'numeric',

app/modules/monitoring/static/admin/js/platform-health.js

@@ -99,7 +99,7 @@ function adminPlatformHealth() {
             if (typeof num === 'number' && num % 1 !== 0) {
                 return num.toFixed(2);
             }
-            return new Intl.NumberFormat('en-US').format(num);
+            return new Intl.NumberFormat(I18n.locale).format(num);
         },
 
         /**