MiniSearch fallback strategy for better-sqlite3 FTS

[themightychris]

The read-api plan calls out a MiniSearch fallback when better-sqlite3 (native bindings) is unavailable on a deploy target. The current implementation in apps/api/src/store/fts.ts only uses better-sqlite3; the fallback was not built, on the grounds that surfacing a clear error at boot is better than silently degrading to a less powerful search backend.

Decision needed:

• Confirm "surface the error" is the right policy long-term (cheaper to ensure native deps build on every target than to maintain two engines)
• Or implement a MiniSearch fallback behind the same FtsEngine interface and gate it on a flag (e.g. an env var or a runtime probe)

Relevant files:

• apps/api/src/store/fts.ts — current engine
• plans/read-api.md — risk note
• specs/architecture.md — "Full-text search — in-memory SQLite FTS5 (or MiniSearch fallback)"

Originated from PR #22 (read-api).

[themightychris]

Decision: fail-loudly at boot is the final answer. Since we only deploy via Docker container, native better-sqlite3 bindings are guaranteed at every target — there's no scenario where the fallback would activate. The current behavior in apps/api/src/store/fts.ts (surface the error at boot) is correct as-is. Closing as decided; the spec line in architecture.md mentioning the fallback can be tightened in a follow-up if desired.