fix: confirm_scars must not green-light a failed retrieval (GIT-93 step 2) - #27

…ep 2)

An empty scar set had two causes and one answer. recall() ran, reached the
store and matched nothing — proceeding is correct. Or recall() never reached the
store — nothing was checked and any warning that applies is still unseen. Both
produced:

  ok  No recall-surfaced scars to confirm. Proceed freely.

This is why step 1 could hide for as long as it did. The *_scar_search RPC 404'd
on every call from the day it was written, and the protocol reported success for
that failure, so nothing accumulated into a signal anyone could notice. Fixing
the RPC name without fixing the signal would leave the next such break equally
well hidden — which is the actual defect worth removing.

recall now records a failure marker on the session when the store cannot be
reached, and clears it when a search succeeds. Cleared on success rather than on
attempt, and independent of how many scars came back: a search that ran and
matched nothing is a real answer; a failed one is not an answer at all.

confirm_scars reads that marker before answering an empty set. On a failure it
returns valid: false, names the underlying error, and says plainly that this is
not the same as no relevant scars.

The marker persists to session.json and is restored on recovery, following
recall_called. A restart is exactly the event this state exists to survive, so
it must not be the thing that launders a broken store into a clean slate.

Verified end to end: with a prefix whose match_<table> function does not exist,
recall 404s and confirm_scars returns REJECTED quoting PGRST202, where it
previously returned "Proceed freely".

+6 tests (1185 -> 1191), including the restart case, and confirmed to fail
against the pre-fix behaviour (2 of 6). provenance-citation.test.ts mocks
session-state and needed the two new exports added to its mock.

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