feat(keyboard): in-keyboard onboarding overlay + AppContext chip

Two long-standing UX papercuts, fixed without leaving the keyboard:

1. **First-launch onboarding inside the keyboard** — iOS keyboard
   extensions *cannot* programmatically switch back to the previous
   app after jumping out, so the old flow (jump to host app → user
   has to manually navigate back) was 5+ taps of friction. The new
   `KeyboardOnboardingOverlay` keeps the user inside the keyboard
   for steps 1 (welcome), 2 (mic permission), 3 (speech permission),
   and 5 (API key hint). The only step that *must* leave is step 4
   ("Enable Keyboard"), which jumps to `Settings.app` via
   `UIApplication.openSettingsURLString` — on return,
   `viewWillAppear` calls `autoAdvancePastKeyboardSetupStepIfNeeded`
   which silently advances past that step if the keyboard is now
   enabled. Net UX: user types in their app, keyboard walks them
   through setup, normal UI appears as soon as setup is done.

2. **Per-app context chip on the keyboard top bar** — the v0.3.0
   intelligent-prompt pipeline already adapted tone to detected
   context (code/email/chat/document), but without a UI cue the user
   had no way to know which mode was active or override the heuristic
   when it guessed wrong. The new `AppContextChip` surfaces the
   detected context; tap-to-override writes back to
   `AppGroupStore.setDetectedAppContext` so the next LLM call
   picks up the new tone immediately. Wired into `pressBegan` so
   the chip updates in real time as the user types into different
   fields.

### Files added
- `OSGKeyboardExt/Views/AppContextChip.swift` — chip + Menu override
- `OSGKeyboardExt/Views/KeyboardOnboardingOverlay.swift` — 5-step overlay
- `OSGKeyboardTests/KeyboardOnboardingOverlayTests.swift` — round-trip + enum surface tests

### Files modified
- `OSGKeyboardShared/Services/KeyboardState.swift`
  + `hasCompletedOnboarding`, `onboardingPage`, `appContext`
  + `setAppContext`, `advanceOnboarding`, `completeOnboarding`
  + `requestMicPermission`, `requestSpeechPermission`, `openSystemSettings`
- `OSGKeyboardShared/Services/AppGroupStore.swift`
  + `hasCompletedOnboarding` / `onboardingPage` accessors (mirror of
    `ProviderConfig` keys, so the keyboard extension never has to
    instantiate the host-app config)
- `OSGKeyboardExt/KeyboardViewController.swift`
  + action hooks wired (`installStateActions`)
  + `syncOnboardingStateFromAppGroup` / `syncAppContextFromAppGroup`
    called on `viewWillAppear` and `loadPersistedConfig`
  + `autoAdvancePastKeyboardSetupStepIfNeeded` for the silent
    "jump out → come back" flow
  + `openSystemSettingsFromExtension` opens `Settings.app` via
    `UIApplication.openSettingsURLString` (the only system URL
    the extension is allowed to open)
  + `detectAndStoreAppContext` mirrors to `state.appContext` so
    the chip updates without waiting for `viewWillAppear`
- `OSGKeyboardExt/Views/KeyboardRootView.swift`
  + overlay mounted in `ZStack` over normal UI (animated)
  + AppContextChip in top bar (hidden during onboarding)
- `OSGKeyboardExt/{en,zh-Hans}.lproj/Keyboard.strings`
  + onboarding copy + chip labels (35 keys per language)

### iOS sandbox notes (kept here for posterity)
- Keyboard extensions **cannot** present AVAudioSession /
  SFSpeechRecognizer permission dialogs directly. The overlay's
  step 2/3 buttons optimistically advance; the actual permission
  is granted when the user first opens the host app (which the
  step-5 "Open OSGKeyboard" button triggers). This is the same
  pattern the previous "jump to host app" flow used — just
  without the broken return trip.
- `UIApplication.openSettingsURLString` is the only system URL
  reachable from `extensionContext.open`. Both step 4 and the
  "Open Settings" button route through `HostAppLauncher` so the
  responder-chain fallback also kicks in if needed.

Co-authored-by: Mavis <Mavis@hkgood.dev>

OSGKeyboardExt/Views/KeyboardRootView.swift

@@ -75,25 +75,40 @@ public struct KeyboardRootView: View {
     }
 
     public var body: some View {
-        VStack(spacing: 0) {
-            headerBand
+        ZStack {
+            VStack(spacing: 0) {
+                headerBand
 
-            Color.clear
-                .frame(height: KeyboardLayoutMetrics.actionClusterTopGap)
+                Color.clear
+                    .frame(height: KeyboardLayoutMetrics.actionClusterTopGap)
 
-            micActionRow
-                .frame(height: KeyboardLayoutMetrics.actionClusterHeight)
+                micActionRow
+                    .frame(height: KeyboardLayoutMetrics.actionClusterHeight)
 
-            Color.clear
-                .frame(height: KeyboardLayoutMetrics.actionClusterBottomGap)
+                Color.clear
+                    .frame(height: KeyboardLayoutMetrics.actionClusterBottomGap)
+            }
+            .padding(.top, KeyboardLayoutMetrics.outerPaddingTop)
+            .padding(.bottom, KeyboardLayoutMetrics.outerPaddingBottom)
+            // 透明背景：让系统键盘 chrome 透出，不自行铺色（深浅模式一致）。
+            .background(Color.clear)
+            .frame(height: Self.totalHeight)
+            // Feed the resolved palette to all nested chips/buttons.
+            .environment(\.themePalette, palette)
+
+            // v0.3.0: in-keyboard first-launch onboarding. Mounted as
+            // an overlay so the normal keyboard chrome stays
+            // responsive underneath (mic button still works, chip
+            // taps register). Only rendered until
+            // `state.hasCompletedOnboarding` flips to true; from
+            // then on the overlay is unmounted and never re-rendered.
+            if !state.hasCompletedOnboarding {
+                KeyboardOnboardingOverlay(state: state)
+                    .environment(\.themePalette, palette)
+                    .transition(.opacity)
+            }
         }
-        .padding(.top, KeyboardLayoutMetrics.outerPaddingTop)
-        .padding(.bottom, KeyboardLayoutMetrics.outerPaddingBottom)
-        // 透明背景：让系统键盘 chrome 透出，不自行铺色（深浅模式一致）。
-        .background(Color.clear)
-        .frame(height: Self.totalHeight)
-        // Feed the resolved palette to all nested chips/buttons.
-        .environment(\.themePalette, palette)
+        .animation(.easeInOut(duration: 0.18), value: state.hasCompletedOnboarding)
     }
 
     /// Top chip row + transcript / hint line.
@@ -131,6 +146,14 @@ public struct KeyboardRootView: View {
             LocaleChip(localeId: state.localeId) { newId in
                 state.setLocale(newId)
             }
+            // v0.3.0: detected app context — the per-app polish mode.
+            // The chip mirrors `AppGroupStore.detectedAppContext` and
+            // writes overrides back so the next LLM call uses the new
+            // tone. Hidden during onboarding (the overlay reads better
+            // without chip clutter).
+            if state.hasCompletedOnboarding {
+                AppContextChip(state: state)
+            }
             // v0.3: always show the translation chip when the active
             // engine can run the cloud LLM step — off-by-default keeps
             // the menu reachable so the user can pick a target language