knowledge-curator: recover inbox notes missing from vault clone via DB fallback

[ExtraToast]

InboxPass.has_work() performed a pure filesystem scan of the vault PVC clone.
A note captured to kb_notes whose file was absent from the local clone — due
to a DB/git desync, a failed push that was retried on a re-cloned PVC, or any
other divergence — would sit with scope = '_inbox' in the database
indefinitely. Every curator tick returned has_work() = False, run() was
never called, and the note was never promoted.

A May 2026 capture (home_direct A records owned by in-cluster cloudflare-ddns)
has been stuck in this state for 19 days.

Fix

has_work() now falls back to a cheap DB existence check when the filesystem
scan finds nothing:

SELECT 1 FROM kb_notes
WHERE scope = '_inbox'
  AND vault_path IS NOT NULL
  AND vault_path NOT LIKE '_inbox/_needs-review/%'
LIMIT 1

If the DB reports work, run() proceeds — vault.sync() pulls from the remote
before the inbox scan, so a file that exists on the remote will be pulled and
processed. If the file is genuinely absent from the remote too, run() returns
no_work safely.

has_inbox_notes() is added to the CuratorStore protocol, PostgresCuratorStore,
and InMemoryCuratorStore. Two new unit tests cover the DB-fallback path and the
_needs-review exclusion.

The stuck May note will drain automatically on the next curator tick without
any manual intervention.