[enaboapps]

Replace runtime SQLite prediction queries with a dedicated ranked lookup loaded once in the existing worker. The lookup preserves the same ordered suggestions and buffered-context behaviour; SQLite remains only in conversion and test tooling. The app packages the generated lookup, with version, checksum, bounds, reference and ordering validation.

The conversion tool reproduces the artifact from the original database, and CI checks it on both platforms. Missing or malformed data uses the existing prediction-unavailable state without disabling keyboard typing. No setting, BLE, scan timing or worker deadline changes.

Closes #819.

Validation:

• Frontend lint, tests and production build passed.
• Rust formatting, clippy with warnings denied, 508 unit tests (one ignored), seven config tests and doc tests passed.
• Dedicated lookup matches the SQLite reference across 1,463 deterministic contexts; loader and Unicode/ranking fixtures pass.
• Converter tests and reproducibility verification passed.
• Independent latest-head review is clean at 8c49f6f.
• Mac VM: packaged development-signed app produced visible suggestions and exact I would like water insertion in TextEdit; buffer-only fixture produced exact was. Unchanged suggestions retained the selected tile. File bytes were checked after insertion.
• Both native workers loaded the packaged lookup and returned suggestions within the unchanged two-second deadline. Raw measurements below.
• Windows interactive validation is BLOCKED: computer control returns windowNotFoundAtPosition for the Parallels window on a secondary display. Worker validation passed, but Windows switch-driven insertion and buffer-only UI tests are not claimed. The user explicitly requested merging with this outstanding limitation on 21 September 2026.
• VM settings were restored byte-for-byte; Windows' previous app was restarted, and Mac returned to its prior suspended state. The signed local Mac app remained running untouched.

Native measurements (startup includes loading and first response, not just database lookup):

VM	First suggestions from launch	Memory	Warm measurement
Mac ARM, release development-signed	730.264 ms	147,521,536 bytes sampled RSS (~140.7 MiB)	1.588 ms observed batch mean
Windows ARM, optimised development build	1,155.887 ms	129,069,056 bytes peak working set (~123.1 MiB)	16.76 ms median, 31.55 ms p95, 43.25 ms max

Memory metrics differ between platforms. Mac batch timing includes native reads and file polling and is not an individual-query distribution. Windows measurements include native caret reads and IPC. Windows used an optimised development manifest; release packaging is checked by CI.

Reproduce with the packaged app and disposable editor focused:

cargo run --release --manifest-path tools/prediction-data/Cargo.toml -- --check src-tauri/resources/WordData2017051601.db src-tauri/resources/word-predictions.lookup
node scripts/measure-macos-prediction.mjs '<app-bundle>' '<app-bundle>/Contents/Resources/resources/word-predictions.lookup'
node scripts/measure-word-prediction.mjs "<windows-executable>" windows-editor water "<packaged-lookup-path>"

Raw Mac result:

{"firstResponseMs":730.247625,"firstSuggestionsMs":730.2637919999997,"count":100,"matched":99,"maxSampledRssBytes":147521536,"warmBatchMeanObservedMs":1.5878800505050443,"elapsedMs":928.0670839999993}

Raw Windows result:

{"app":"windows-editor","firstResponseFromSpawnMs":1114.4775410000002,"firstSuggestionsFromSpawnMs":1155.8870829999996,"memoryBytes":129069056,"memoryMetric":"peakWorkingSetBytes","successfulSamples":100,"unsupported":1,"failures":0,"fixtureMatches":100,"firstRequestMs":1084.47,"medianMs":16.76,"p95Ms":31.55,"maximumMs":43.25}

The initial unsupported response is buffer seeding; subsequent requests returned candidates. No input is injected by these measurement helpers.