[enaboapps]

This experimental branch uses native predictions first in the scanning keyboard and the existing database when native generation fails, times out or returns no usable candidates. The existing prediction setting controls it; no saved schema, BLE, provider selector or cloud service is added.

Stacked on #796 (codex/word-prediction-795) so the review contains only spike changes. Keep draft until the findings are reviewed. Retarget to main after #796 merges; merging, releasing or choosing the shipping default require separate instructions.

Changes

• Shared typed provider interface inside the bounded prediction worker; native calls run in a disposable child with a 600 ms deadline inside the existing two-second worker limit.
• Mac: NSSpellChecker completions with surrounding text, UTF-16 prefix ranges and an available UK dictionary (generic English fallback); zero-length ranges for observed next-word behaviour.
• Windows: TextPredictionGenerator with Predictions explicitly enabled, UK-to-US retry after unusable candidates, and the next-word API at boundaries.
• Preserve native order; filter empty, duplicate, multiline and prefix-incompatible candidates. Shared extraction, protected/stale-context checks, suffix-and-space insertion, cancellation and unchanged-result caching remain in place.

Results and recommendation

Reproduction, raw synthetic measurements and qualification report.

The exact helper path completed 120 online/offline requests across both ARM VMs with no native errors, empty usable lists or database fallback. Median native latency was 53–54 ms on Mac and 148–149 ms on Windows; maximum was below 180 ms. Offline runs used disconnected VM adapters and failed external connectivity checks, with local host transfer still reachable.

Neither provider is qualified for production. Mac is the stronger candidate for a later trial, but the corpus is small and zero-length completion behaviour needs testing across supported OS versions. Windows needs broader locale/language-pack coverage.

Interactive qualification remains blocked: a Mac follow-up using J/K/L switch bindings verified keyboard opening, row/key navigation, exactly-once h insertion, Space insertion and switch-accessible Close, with TextEdit focus retained. The suggestion row remained empty for hel and at a word boundary despite useful standalone native results; the integrated context/worker/provider path needs investigation before suggestion acceptance can be qualified. Windows computer control did not reliably deliver unrelated input even with Switchify stopped. Suggestion insertion, repeated switch typing, focus/selection/protected-field cases and stable live row timing are not marked passed.

Validation and restoration

• Frontend lint/tests/build; Mac Rust format, Clippy and tests passed: 450 unit + seven integration tests, one manual benchmark ignored.
• Windows ARM64 Clippy/tests passed: 447 unit + seven integration tests, one manual benchmark ignored and the native overlay smoke test excluded from the headless runner. Both platform debug builds succeeded.
• Fake-provider/input coverage includes rank/filtering, fallback, locale retry, invalid contexts, identical-result caching, exactly-once insertion and hanging-helper termination. Shared prerequisite tests cover cancellation and stale/protected contexts.
• VM settings restored byte-for-byte, networks reconnected, previous Add offline word prediction to the scanning keyboard #796 Windows app restarted, Mac spike stopped and VM suspended again. No new permissions or security-policy changes; signed local Mac app untouched. The disposable Windows Notepad tab may remain open because UI control was unavailable.
• Independent review of latest head 97f45136a1ad9d9569ba38ae51297d01f1f6b128 found no actionable issues. The Mac orphan-at-startup cleanup guard passed its subprocess regression test and the full Rust suite. All final-head CI checks passed: frontend, dependency audit, Mac native build and Windows native/UIAccess packaging. CI run.

Closes #797