Daemon-enabled semantic search silently falls back after DaemonFallbackEmbedder API hardening

[lifeofgurpreet]

Current CASS main is wired to a Frankensearch API that deliberately rejects the legacy daemon wrapper:

• src/lib.rs:compose_daemon_embedder_or_verified_local calls DaemonFallbackEmbedder::new(...).
• In frankensearch-fusion/src/daemon_fallback.rs, that constructor now always returns UnverifiableRemoteSpace because caller-supplied daemon identity is not producer proof.
• CASS catches that error and silently returns the local fallback embedder. Thus cass search --mode semantic --daemon cannot actually use an otherwise healthy local daemon.

Independent reproduction on a 2,573,003-vector CASS corpus:

1. The CASS daemon starts the local MiniLM model in ~2 seconds and reports a 184 MB peak; its 90-second idle shutdown works.
2. A daemon-enabled semantic approximate query instead grew to ~4.8 GB RSS locally before reaching ANN.
3. After the fallback eventually completed, the repaired packed HNSW sidecar was mapped and ANN itself took only 99,467 us for ef=100, 16 candidates, with is_approximate=true and estimated recall 0.956. Total request time was 308,436 ms and exceeded CASSs 120-second query budget.

This is not an argument to restore unverified remote vectors or keep an HNSW service warm. The safe fix is to update CASS + its local daemon protocol to supply a verifiable DaemonConnectionIdentityV1 and pinned attestation verifier, then construct DaemonFallbackEmbedder::new_verified (and the corresponding reranker wrapper). Until then, the daemon flag presents an availability path that is structurally forced into expensive direct inference.

The source lock and local Frankensearch checkout are both at 46a3aefce1aa658fa98f27f0b3676f073160e15c; this is an integration contract mismatch, not a version-skew guess.

[Dicklesworthstone]

Confirmed against the pinned frankensearch rev (46a3aefc): DaemonFallbackEmbedder::new unconditionally returns UnverifiableRemoteSpace, and compose_daemon_embedder_or_verified_local swallowed that into a debug-level trace and handed back the local embedder. So yes — with a reachable warm daemon, --daemon (and the default daemon discovery) was structurally forced into full in-process model load + direct inference. This is an integration contract mismatch on cass's side, not a version skew.

Two things, split deliberately:

1. Landed in 2a1fc6f: the fallback is no longer silent. When a daemon is actually reachable and bypassed, cass now prints a stderr warning naming the cause and pointing at --no-daemon; the no-daemon case stays quiet because that is the ordinary local path. Stdout stays data-only.

2. The real fix is tracked as coding_agent_session_search-zn7zn (P1): teach cass's daemon client and server the attested protocol — DaemonClient::{handshake,health,embed,embed_batch}_attested answering DaemonChallengeV1 with an HMAC-SHA256 DaemonEmbeddingAttestationV1 under a per-data-dir pinned key, a DaemonConnectionIdentityV1 derived from the native embedder's EmbeddingIdentityBundleV1, and composition via new_verified (plus the reranker wrapper). That is a protocol change on both ends with key provisioning, so it is its own change rather than something to squeeze into this triage pass. Agreed that restoring unverified remote vectors is not on the table.

Your 2.57M-vector numbers (4.8 GB RSS before ANN, ~99 ms ANN, 308 s total) are the benchmark I'll use to validate the attested path when it lands.