v7.74.1

Pairs with engine-service-v0.1.151, unchanged from 7.74.0 (REQUIRED_ENGINE_VERSION stays 0.1.151); a client-only patch. Search and query against the managed service were slow because the vector client opened a new TCP and TLS connection for every request; this release reuses connections and removes work query never used. The larger server-side fixes (search returning vectors, gzip, a faster stats view) ship with the next engine tag and the client release that pins it.

Fixed

• nx uninstall --yes --remove-data leaves less behind (nexus-25wlq, RDR-224). The engine's DJL tokenizer cache now lives under ~/.cache/nexus/djl (the engine is started with DJL_CACHE_DIR there unless you set one), so the model-cache removal takes it; a ~/.djl.ai from an earlier release is named in the report and kept, because other Java programs share it. On Windows the last engine run's onnxruntime-java<digits> folders under TMP (else TEMP) are removed after a confirmed stop, by the engine's own sweep rules and a narrower name match. A clean Windows 11 walk found 24 MB left over from these two.
• On Windows the nx uninstall preview names the Task Scheduler task it would remove, not a Linux unit, and tells a CLI user to re-run with --yes (nexus-25wlq). The MCP tool keeps its confirm=true wording.
• A default nx search no longer warns that no knowledge (or code, or docs) collection matched (nexus-25wlq). The default corpus spans all three, so a missing leg there is not news; an explicit --corpus still warns.
• nx index md, nx index pdf and nx collection reindex chunk a bge collection to its 512-token window, and stop warning embed_window_tokenizer_missing about a MiniLM tokenizer (nexus-25wlq, RDR-224). They took the window from the Python embedding function's model, which on a service-backed local install is MiniLM while the engine embeds bge-768, so chunks were checked against the wrong window (or none) and every run looked for a tokenizer at a Chroma-era path. The window now follows the collection name's model token, as nx index repo already did. Without the window, a markdown or PDF chunk denser than the chunker's character estimate (a whole code block, a table, non-English text) went past bge's 512 tokens and the engine truncated it when embedding, so search could not see its tail. Files indexed before this release keep those chunks until they change or are re-indexed with --force. A --force re-index re-chunks, and a link anchored to a chash: span on a re-chunked document stops resolving (docs/catalog.md § Span lifecycle), so check nx catalog link-audit first if you link to passages.
• The MCP query tool does less work per call (nexus-tnwm2). It inherited the search default of grouping results by topic, which fetched every topic's label one request at a time, and it never shows that grouping. It now turns grouping off and reads every result document's chunk count in one manifest call instead of one per document: 9 taxonomy requests become 2 and 7 manifest calls become 1 for a seven-document answer.
• The vector client reuses its HTTP connections (nexus-qjjlz). _request_once built a fresh urllib opener per request and urllib forces Connection: close, so every /v1/vectors call paid a TCP and TLS handshake and started TCP slow-start cold; a search makes about 28 such requests, many in parallel. Measured against the cloud, /version took 0.23 to 0.43 s on a new connection and 0.073 s on a reused one. A process-wide pool (nexus.db.pooled_http) now keeps idle connections per resolved endpoint, so lease rotation still works (a changed endpoint is a different pool key), thread-safe for the 8-way fan-out, reset in a forked child, and a connection the server closed while idle is replaced with one retry on a fresh connection. The urllib error taxonomy the retry wrapper classifies, the TCP keepalive options, proxy handling and the data-token and header handling are unchanged. The client also sends Accept-Encoding: gzip and decodes gzip responses; the engine does not compress yet.