postgres: verify hnsw_ef_search is applied by the scan path

[ruvnet]

Field report / investigation

On a degraded 178k-row PostgreSQL HNSW graph, sweeping ruvector.hnsw_ef_search across 40, 100, 200, and 400 produced identical self-recall (141/200) and approximately flat latency (~4 seconds per 200-query probe).

hnsw_am.rs documents the GUC with default 40 and dynamic adjustment based on recall target, but the observation suggests either:

• the scan path does not read the GUC; or
• dynamic adjustment overrides it without clear documentation.

Acceptance criteria

• Add an integration test proving scan behavior/visited-candidate count changes when the GUC changes, or document and test the override rule.
• Ensure EXPLAIN/diagnostics expose the effective ef where practical.
• Cross-check the analogous note that VectorDB::search ignores SearchQuery::ef_search in ruvector-sota-bench/src/runners/core_hnsw.rs.

Provenance

Salvaged from production field report PR #716 (DreamLab AI / agentbox operators). A non-concurrent rebuild recovered recall from 141/200 to 177/200, confirming the harness was sensitive to index quality.