[EPAC-2075]: build SearchHansard use case and FTS5 query adapter

[riddim-developer-bot]

Why

The hansard-search Lambda had the D1 scaffold and index loader, but no query-layer policy or SQLite adapter. This adds the SearchHansard use case, typed validation/query-syntax errors, and the FTS5 repository implementation so D3 can wire the HTTP handler onto a tested search boundary instead of embedding SQL in transport code.

What changed

• Added internal/usecase/search_hansard.go with the search value types, pagination, repository port, and input validation for empty queries and invalid page/per-page values.
• Added internal/adapter/sqlitefts5 with the FTS5 MATCH/COUNT(*) queries, speaker/topic substring filters, control-character sanitization, snippet/bm25 mapping, and typed ErrInvalidQuerySyntax translation for modernc.org/sqlite parser failures.
• Added fixture-backed adapter tests covering word match, phrase match, boolean operators, speaker/topic filters, pagination, empty results, and the invalid-syntax path.
• Updated the hansard-search README and use-case catalog so the new backend boundary is discoverable, and removed the stale D2 note from OpenSearchIndex.

Trade-offs not taken

• I did not wire the HTTP handler or OpenAPI surface here; that remains D3 per the ticket scope.
• I kept the fixture database test-local instead of committing a binary SQLite artifact so the corpus stays easy to inspect and adjust in Go.

Test plan

• GOWORK=$PWD/backend/go.work go test ./backend/hansard-search/...
• go test ./... (from backend/hansard-search)
• go test ./hansard-search/... (from backend)

Skipped checks

• cd ios && make build was not run because this ticket only changes the Go backend hansard-search module.
• No OpenAPI update is included because this PR does not add or change a live endpoint yet; D3 owns the handler wiring and spec change.

Reviewer-Boundary: review-only

Linear: https://linear.app/riddimsoftware/issue/EPAC-2075/build-searchhansard-use-case-and-fts5-query-adapter-for-hansard-search