fix: report the typed-fact backlog nothing will drain

[JBailes]

Two gates that do not agree

memory.store enqueues a memory_facts job whenever typed_facts_enabled is on — the default:

if (config_typed_facts_enabled() && out.id > 0)
   (void)db2_kb_async_enqueue("memory_facts", out.id, "memory");

The only consumer of those jobs is kb_memory_facts_drain, which runs on the curator LLM lane. That lane deliberately does not start without a synthesis endpoint:

/* NO SYNTHESIS PROVIDER => NO LLM LANE. ... running them anyway is not merely idle */

Both decisions are individually correct. Together they mean an install with no synthesis provider — a supported configuration — enqueues one row per stored memory that nothing will ever claim.

Found by exploratory testing, not by a failing check

On the e2e VM:

• 4 memory_facts jobs pending for 11.5 hours, attempts=0 — never even claimed
• /v1/health → status: ok, warnings: [], blockers: []
• aimee kb status → Queue: 4 pending, 0 running, 0 failed, with nothing to say that pending here means forever

It grows without bound for the life of the install. Same family as #2319 and #2321: the evidence existed, the summary did not carry it.

Reported as a warning, not a blocker

Running without a synthesis provider is explicitly supported, and memory store and search work perfectly — only typed-fact enrichment is deferred. Degrading the verdict for a supported configuration is exactly the dilution the status derivation added in #2319 exists to avoid. This is the distinction that PR built, being used as intended.

The message also says the backlog is not lost: configuring a provider drains it. That is why the fix is not "stop enqueueing" — the queue is a backfill, and dropping it would silently forfeit facts for every memory stored before a provider was configured.

Counting needs pending, not total

db2_kb_async_count_kind counts every row regardless of status. That cannot distinguish a queue that is draining from one that never will — which is the entire distinction being reported — and would keep warning about work that already completed. Added db2_kb_async_count_kind_pending alongside it.

Verification

Test asserts pending tracks the backlog rather than the row total: two enqueued → 2 pending / 2 total; one marked done → 1 pending / 2 total; an extract_doc row in the shared table is not counted in. Red verified by dropping the status = 'pending' filter — fails on exactly the pending-vs-total assertion.

Lockfile: kb-synthesis source pin resynced, recomputed with the exporter's own digest functions.

Gate: clang-format → make lint (41/41) → check-docs.py → check_c_repository_lock.py — all green.