docs+test: align white-screen evidence with public vue-i18n API

Address reviewer round-2 fail-closed feedback on 333f6cc:
- Incident doc no longer claims the regression uses @intlify/message-compiler
  baseCompile; it states the regression uses vue-i18n's public createI18n/
  global.t API recursing nested objects and arrays.
- The placeholder render assertion now runs inside the locale loop, so both
  Thai and English are each explicitly asserted to render name@company.com
  (previously only the final English locale was asserted after the loop).

Verified: frontend tests 11 passed; production build index-B4oVHpLg.js passed.

docs/engineering-log/2026-09-01-login-white-screen.md

@@ -36,7 +36,7 @@ A RED regression test that compiles every Thai and English message failed specif
 ## Fix
 
 - Escape the literal at-sign using vue-i18n syntax: `name{'@'}company.com` in both locales.
-- Add a recursive contract test using `@intlify/message-compiler` `baseCompile` for every string in both translation dictionaries.
+- Add a regression contract test that translates every string in both language dictionaries through vue-i18n's public `createI18n`/`global.t` API (recursing nested objects and arrays) and asserts the placeholder renders as `name@company.com`.
 
 The rendered translation remains `name@company.com`.
 

frontend/tests/i18n-contract.test.mjs

@@ -63,9 +63,14 @@ test('every translation message compiles through the vue-i18n public API', () =>
         `${locale}:${keyPath} is not valid vue-i18n syntax`,
       )
     }
+    // The visible email placeholder must render as a literal email in both
+    // locales; vue-i18n must not misparse it as linked-message syntax.
+    assert.equal(
+      i18n.global.t('auth.emailPlaceholder'),
+      'name@company.com',
+      `${locale}:auth.emailPlaceholder`,
+    )
   }
-
-  assert.equal(i18n.global.t('auth.emailPlaceholder'), 'name@company.com')
 })
 
 test('frontend i18n uses Thai as the safe default and fallback', () => {