fix: call the retrieval RPCs by their deployed names (GIT-93) - #26

recall has two paths: a local vector index, and a Supabase RPC fallback used
whenever that index is not ready. The fallback returned PGRST202 on every call.

scarSearch and semanticSearch built the RPC name by taking the TABLE prefix and
appending a verb:

  const rpcName = `${getTableName("").replace(/_$/, "")}_scar_search`;

which is "orchestra_scar_search" under GITMEM_TABLE_PREFIX=orchestra_ and
"gitmem_scar_search" by default. Enumerating the functions PostgREST actually
exposes turned up neither, under any prefix — nor any *_scar_search at all. The
deployed names are match_<table> and match_<table>_weighted, so the RPC is named
after the table it searches, not after the prefix with a verb glued on. The
docstrings claiming gitmem_scar_search / gitmem_semantic_search described a
function that does not exist; they are corrected too.

So this was never a prefix mismatch that a non-default deployment tripped over.
The fallback had not worked on any deployment since it was written. It stayed
invisible because it is only reached while the local index is cold — a window
that happens to include the first recall of every session, the one the
SessionStart hook triggers, which is the recall that gates the work about to
be done.

_weighted is the correct one of the pair for scarSearch: that function is
documented as scar search with severity weighting, and it is the variant
returning decay_multiplier, which recall consumes. It takes match_threshold
rather than similarity_threshold, so the body changes with the name.

project_filter is deliberately not sent. This stands in for the unified
cross-project vector cache; filtering here would make the cold path return a
narrower set than the warm path it substitutes for — a silent behaviour change
on precisely the calls that are hardest to notice.

Verified end to end against the real store: a recall issued before
"[startup] GitMem initialized" now returns 3 scars with no PGRST202, where it
previously returned none. +5 tests (1180 -> 1185), hermetic (fetch stubbed,
asserting the URL), and confirmed to fail against the pre-fix names.

Not fixed here: with nothing surfaced, confirm_scars still reports "No
recall-surfaced scars to confirm. Proceed freely." — a green result for a
failed retrieval. Tracked on GIT-93 as step 2, and it is the reason this bug
could persist unnoticed.

Co-Authored-By: Claude Opus 5 <[email protected]>