ci: fix OOM-killed test step (256Mi LimitRange) + document recall limits

The Forgejo build pipeline (woodpecker repo 158) has failed on every run
since the 2026-05-07 Forgejo-only switch: the `test` step was OOM-killed
(exit 137) during `mypy` because the woodpecker namespace LimitRange
defaults containers to a 256Mi memory limit, and `uv sync` + mypy over
fastapi/pydantic/sqlalchemy needs far more. As a result the recall-limit
fix (1c0193f0) could not be built/deployed.

Pin explicit memory (req 1Gi / limit 2Gi) on the `test` and
`build-and-push` steps via backend_options.kubernetes.resources, matching
the in-repo pattern (infra/.woodpecker/default.yml). Also document the
recall default limit (30) and the relevance-bound OR-broadening fallback
in README.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

README.md

@@ -230,6 +230,10 @@ LIMIT $3
 - `sort_by="relevance"` — `ORDER BY ts_rank(search_vector, query) DESC`
 - `sort_by="recency"` — `ORDER BY created_at DESC`
 
+**Result limit:** `limit` defaults to **30** — recall returns a small top-N of the most relevant matches, not the whole store. The ceiling is 10000 for callers that explicitly opt into more.
+
+**OR-broadening fallback:** the query above is an AND-match (`plainto_tsquery` requires every query word to be present). When it returns fewer than `limit` rows and the query has more than one word, recall widens to an OR-match (`to_tsquery` joining the words with `|`) to fill the result set. Those broadened rows are ordered by `ts_rank` relevance (as in `sort_by="relevance"`) and must clear a minimum-rank floor (`OR_BROADEN_MIN_RANK = 0.01`) — a memory that merely contains one query word incidentally is dropped as noise rather than padding the results.
+
 ### Semantic Expansion at Store Time
 
 When Claude stores a memory via `memory_store`, it generates an `expanded_keywords` field — at least 5 space-separated semantically related terms. For example, storing "User prefers Svelte for frontends" might produce: