[P0-③] API Key data flow fix

- AppGroup.defaults: in DEBUG, missing App Group is a hard fatalError
  with a precise remediation message (was a soft print + .standard
  fallback, which desynced the keyboard extension from the main App).
  Release keeps the fallback + NSLog so end-users still get a usable app.
- KeyboardViewController.loadPersistedLocale now prints a masked DEBUG
  view of the live App Group config (provider, baseURL, masked key,
  model, mode, locale) so the extension's view is visible in the
  device console.
- KeyboardViewController.handleFinalTranscript now routes by typed error:
    noAPIKey  → red error '未配置 API Key · 请在主 App 设置中填写'
    http 401  → red error 'API Key 无效 (401) · 请检查主 App 设置'
    http 429  → red error 'API 限流 (429) · 请稍后再试'
    other     → insert raw transcript + generic error badge
- APISettingsCard gains a 'Test connection' button that runs a single
  client.polish('ping') round-trip and surfaces the typed result inline.
- PolishingService.timeout raised 12s → 15s to match LLMClient.request
  timeout (was racing and discarding successful responses in 12–15s).
- Tests: 4 new cases (HTTP 429, transport timeout, App Group cross-process,
  AppGroupStore→LLMClient noAPIKey). All 8 tests pass on iPhone 16e sim.

xcodebuild iOS Simulator: SUCCEEDED
xcodebuild test: 8/8 passed

OSGKeyboardShared/Constants/AppGroup.swift

@@ -12,21 +12,40 @@ public enum AppGroup {
 
     /// Shared UserDefaults instance for cross-process config.
     ///
-    /// Falls back to `.standard` if the App Group isn't available (e.g.
-    /// the user hasn't created the App Group in the Apple Developer
-    /// portal, or Xcode hasn't downloaded a matching provisioning profile).
-    /// In that mode, the keyboard extension will *not* see config written
-    /// by the main app — but the main app itself stays usable so the user
-    /// can fix the signing situation without the app crashing.
+    /// In DEBUG builds a missing App Group is a hard `fatalError`: silently
+    /// falling back to `.standard` desyncs the keyboard extension from the
+    /// main App (the extension would write to one suite and the main App
+    /// would read from another, or vice-versa) and the symptom is "I gave
+    /// the App an API key and nothing happens" — which is exactly the bug
+    /// this is meant to prevent.
+    ///
+    /// In release builds we keep the soft fallback + `NSLog` so an
+    /// end-user whose developer account simply lacks the App Group still
+    /// gets a usable main App (the keyboard extension won't work, but at
+    /// least the App doesn't crash on launch).
     public static var defaults: UserDefaults {
         if let d = UserDefaults(suiteName: identifier) {
             return d
         }
         #if DEBUG
-        print("⚠️ App Group \(identifier) unavailable — falling back to .standard. " +
-              "Add the App Group in your Apple Developer account and Xcode " +
-              "Signing & Capabilities, then re-run.")
-        #endif
+        fatalError("""
+        ⚠️ App Group \(identifier) unavailable.
+
+        Add the App Group in:
+          1. Apple Developer portal → Identifiers → App Groups → add
+             \(identifier)
+          2. Both bundle IDs (main app + keyboard extension) → enable
+             that App Group under Capabilities
+          3. Re-generate the provisioning profile, download it, and
+             re-run the project.
+
+        Falling back to .standard would silently desync the keyboard
+        extension from the main App — a hard crash in DEBUG is the
+        only way to make the misconfiguration impossible to miss.
+        """)
+        #else
+        NSLog("⚠️ [OSGKeyboard] App Group \(identifier) unavailable, falling back to .standard. The keyboard extension will not see config written by the main app.")
         return .standard
+        #endif
     }
 }