Function consolidate_looks_incomplete 

pub fn consolidate_looks_incomplete(
    conn: &Connection,
) -> Result<bool, StoreError>

True when the backfill’s source tables have data but its target (db_agents) doesn’t — i.e. a marker (or a db_migrations stamp) claims this migration ran, but the data it’s supposed to have produced isn’t there. Used to stop trusting marker/stamp existence as proof of effect (see docs/specs/SPEC_MIGRATION_SYSTEM_HARDENING_2026_08_03.md Phase 0a/0b) — a stale marker (rebuilt/restored objects.db sitting next to an old flag file, or m0000_bootstrap stamping from a copied flag file with no matching data) is now detectable instead of silently trusted.

Cheap: up to three COUNT(*) queries, safe to call on every startup.

Tolerates either source table being physically absent (Phase 3e, SPEC_AGENT_ARCHITECTURE_2026_05_27.md — db_agent_definitions/ db_agent_instances are dropped by m0029_drop_legacy_agent_tables): an absent table categorically has no rows, so it can never be the “source has rows but the target doesn’t” shape this function detects. Load-bearing, not defensive-only — a fresh (v32+) channel is stamped 0007_agents_consolidate applied via its own early-return no-op (m0007_agents_consolidate.rs::up’s channel_store_path.exists() guard, for a channel created before migrations ever ran), and a later muxspect migrations --verify doctor pass calls m0007’s verify() — which calls this — against that channel once it has real, ordinarily- populated db_agents data. Without this guard that doctor pass would error on “no such table” for every fresh install, not just an upgraded one that genuinely went through the old table pair.