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>

.woodpecker/build.yml

@@ -12,6 +12,18 @@ clone:
 steps:
   - name: test
     image: python:3.12-slim
+    # The woodpecker ns LimitRange defaults containers to a 256Mi memory limit.
+    # `uv sync` + mypy over fastapi/pydantic/sqlalchemy needs far more, so the
+    # step was OOM-killed (exit 137) on every run since the 2026-05-07 Forgejo
+    # switch — repo never built. Pin explicit memory so it never OOMs again.
+    backend_options:
+      kubernetes:
+        resources:
+          requests:
+            cpu: 500m
+            memory: 1Gi
+          limits:
+            memory: 2Gi
     commands:
       - pip install --no-cache-dir uv
       - uv sync --all-extras
@@ -23,6 +35,15 @@ steps:
     image: woodpeckerci/plugin-docker-buildx
     depends_on:
       - test
+    # buildx + image export also exceeds the 256Mi ns default; give it room.
+    backend_options:
+      kubernetes:
+        resources:
+          requests:
+            cpu: 500m
+            memory: 1Gi
+          limits:
+            memory: 2Gi
     settings:
       # Phase 4 of forgejo-registry-consolidation 2026-05-07 — Forgejo only.
       # The DockerHub mirror stays as the public-facing release target via

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: