perf(knowledge): facts/by_category uses SMEMBERS+sorted() per request (no server-side SET pagination); legacy SCAN offset unstable #12426

Low-urgency follow-ups noted in PR #12424 (#12394) review — non-blocking, tracked for scale:

1. _fetch_category_fact_ids loads ALL fact IDs per category via SMEMBERS + sorts O(N log N) every request. Fine today (only the sliced facts' CONTENT is fetched; matches the sibling knowledge_categories convention; default browse iterates just 3 KnowledgeCategory members). Becomes a per-request CPU/memory cost only if a single category grows to ~millions of facts — then it'd want server-side SET pagination (e.g. a sorted-set ZRANGE index).
2. _get_facts_by_category_legacy (degraded no-index SCAN path) paginates over UNSORTED scan order → offset windows not stable across calls. Documented as 'good enough' for the fallback; only matters if that path is exercised interactively.
3. UX: folder badges (categoryCounts) show 'loaded so far', not the new total_count — consider 'X of Y'.
   Refs perf(knowledge): paginate facts/by_category (unbounded list) #12394 perf(knowledge): facts/by_category browse list ships full_content (107KB/fact) → 3MB for 43 facts, unpaginated; detail endpoint already exists for lazy-load #12370.