Baixar ivygrep 1.3.0 per a Windows

### Upgrade notes

• The default neural model is now `potion-code-16m-v2`. Indexes keep working without a rebuild and the index format is unchanged：search ignores neural vectors built by `static-retrieval-v1` and answers from lexical, literal, symbol, and hash evidence until the next neural enhancement re-embeds the index, which the daemon schedules after the first search (done within 8 seconds for 11,214 chunks in a local run; a direct rebuild embeds 25,460 chunks in 6 seconds). Until then `--force-neural` reports an incompatible neural model, and `ig --status` and `ig --doctor` report a healthy index that still lists `static-retrieval-v1`. The first neural use downloads 33.5 MB instead of 125.7 MB. Hosts without network access need the new model in the Hugging Face cache (`uv run scripts/cache_neural_model.py --profile potion-code-v2 --cache "$HF_HOME"`); without it neural enhancement fails and search stays on lexical and hash results. Set `IVYGREP_MODEL_PROFILE=static-retrieval-v1` (or `static`) to keep the previous model, its cached download, and existing vectors.

### Changed

• Neural search results now depend on how good the embedding model is, and the default neural profile is `potion-code-16m-v2` instead of `static-retrieval-v1`; an unset or unknown `IVYGREP_MODEL_PROFILE` selects it (see the upgrade notes). Until now the neural tier was one reciprocal-rank vote of weight 1.0 among lexical, literal, path, and symbol votes worth several times more, and only files among the 50 nearest chunks got it, so a better model changed almost nothing：on the public benchmarks `potion-code-v2` beat `static-retrieval-v1` by .003 nDCG@10 in default mode although its own ranking is far better. A late dense-fusion stage now runs after the ranking heuristics and before result filtering and the learned reranker. Search scores every candidate that lexical, literal, path, or symbol search found against the neural query vector, then reorders files by two signals. A file whose best cosine beats the runner-up file by a ratio of 1.05 moves to the first position. Profiles with a measured calibration (`DenseFusionCalibration` in `src/embedding.rs`; `potion-code-16m-v2` uses 0.25 for pasted source and for multi-line or long prose) also add a standing reciprocal-rank vote, and search consults them for every query whose route allows neural retrieval instead of only when lexical confidence is low. `static-retrieval-v1` and unmeasured profiles have no standing vote and keep the lexical-confidence gate. Only files that direct search found, that pass the result filter's authority test, and that have the most authoritative path role among the direct candidates take part, and they are reordered among the positions they already hold, so cosine alone never promotes a file and documentation, tests, and support files never move relative to the implementation. Short natural-language queries skip the stage. Scores are reassigned by position, so the adaptive score filter and the learned reranker see the same distribution as before. All figures are measured on top of the long-query lexical vote in this release, against `static-retrieval-v1` as the default without the new stage. On 923 held-out public queries (the public-core halves the reranker was not fit on, four `sota-challenge` samples, and CodeSearchNet Python and Java), default-mode nDCG@10 rises by .011 (102 queries up, 68 down; CodeSearchNet-java .677 to .727, codefeedback-st .779 to .803, codetrans-contest .588 to .609): .008 from the new stage with the same model (.009 with `--force-neural`) and .003 from the model. On the file-localization benchmark default mode goes from Acc@1 .367 to .400, Acc@5 .767 to .800, Acc@10 .767 to .833, and MRR .524 to .551. On MemoryQuest notes retrieval nDCG@10 goes from .435 to .455 and recall@20 from .753 to .764. The self-repository relevance gate ranks every query the same in every mode, and lexical, hash, and hybrid results without neural vectors are identical. With `IVYGREP_MODEL_PROFILE=static-retrieval-v1` no default-mode query changes. The new model is a quarter of the download, index size is unchanged (256 dimensions, f16), both models embed 25,460 chunks in 6 seconds, and peak memory during that enhancement is 140 MiB against 179 MiB. CI and release acceptance now cache and validate the default profile (`Model2Vec token mean via Rust`), and benchmark results recorded without `IVYGREP_MODEL_PROFILE` are attributed to `potion-code-16m-v2`.
• The static musl builds for Linux, which `install.sh` and the Homebrew formula install, use jemalloc as their allocator on 64-bit targets. musl's own allocator takes one lock for every thread, and ivygrep allocates from many threads at once：a full index plus enhancement of this repository took 30 s with the musl archive against 5 s with a glibc build, and a daemon under 64 `ig --mcp` sessions served 34 calls per second against 159, with a median hybrid search of 1.6 s against 0.3 s. With jemalloc the same index takes 6 s and the daemon serves 65 calls per second at a median of 0.7 s. The daemon uses more memory under that load (425 MiB instead of 236 MiB, a glibc build 688 MiB) and about the same when idle; an idle `ig --mcp` session goes from 1.2 to 1.8 MiB, still 3 threads. jemalloc fixes its page size at build time and aborts on a kernel with larger pages, and aarch64 kernels use 4, 16, or 64 KiB, so the aarch64 archive is built for 64 KiB (`.cargo/config.toml`). `ig hardware` now reports the allocator and, for jemalloc, that page size (`allocator` in `--json`), and the release and E2E workflows assert it for the musl archives, because emulation with 4 KiB pages cannot. glibc, macOS, and Windows builds keep their system allocator and report `system`.

### Fixed

• The daemon closes a connection that sends no complete request line within 10 seconds. Connections that never sent a request, or sent bytes without a newline, held their slot until the client closed them, so 512 of them locked other clients out with busy errors. Running requests, such as long searches and indexing, have no such bound.
• The MCP server keeps reading stdin while a tool call runs. `ping` gets an answer right away, and `notifications/cancelled` drops a queued request or stops a running hybrid, literal, or regex search (including those in a context pack), daemon search, or first-index wait, with no response for the cancelled request. Previously the server read the next message only after the current request finished, so a ping during a first index waited for the whole call (18.4 s in a local run) and cancellations had no effect. Requests still run one at a time in arrival order, and requests already read still run after stdin closes.
• A newline-delimited MCP message over 16 MiB gets a `-32700` parse error with a null id, and the session continues with the next line. Previously it ended the session. Malformed `Content-Length` framing still ends the session.
• Multi-paragraph prompts, pasted issue text, and questions with a blank line are ranked as prose instead of pasted source. In v1.2.16 every multi-line query left the signature field out of lexical scoring, stopped turning `owner.member` mentions into exact-symbol lookups, and kept hash votes on direct candidates. Multi-line input is now pasted source only when it reads as code：at least half of its words sit on code lines (ending in `;`, `{` or `}`, indented, or with as many code-shaped tokens such as `=`, `snake_case`, `owner.member` or `call(arg)` as words) or are code-shaped themselves. Multi-line prose scores signature matches like body matches instead of at 5x, looks up `owner.member` mentions, and gives hash matches on direct candidates no fusion vote. Pasted source and multi-line pasted error output keep v1.2.16's rules, and an explicit `signature:` clause keeps its 5x boost in any query. On 24 multi-paragraph agent tasks, issue reports, and questions about ivygrep's own source, MRR on the held-out half rises from .708 to .750 in foreground mode and from .757 to .808 in neural mode. On public-core codefeedback-st, lexical nDCG@10 rises from .7189 to .7227 and recall@20 from .8182 to .8283. codetrans-contest, codetrans-dl, and cosqa lexical results are unchanged, and the self-repository gate gives identical results. Scoring prose signature matches at 5x instead would have dropped codefeedback-st lexical nDCG@10 to .6301.
• Multi-line classification from the previous entry reads more pastes and prompts correctly. Pasted code led by import statements (`import numpy as np`, `from … import …`, and `require`, `use` or `package` with one argument) is pasted source again：a snippet with two import lines and three `plt.` calls read as prose, so `plot`, `savefig`, and `show` became exact-symbol lookups and one-line definitions of those names outranked the code that contains the snippet. Indented paragraphs and hard-wrapped list items under prose, Markdown tables, rules, and heading marks, `？`, `。`, curly quotes, and `…`, issue references, versions, and sizes such as `#375`, `v1.2.16`, and `2.3GB`, and `e.g.` and `and/or` no longer make prose read as pasted source. In multi-line prose, `owner.member` mentions become exact-symbol lookups only on prose lines and only when written as a call, in backticks, or with a camelCase member, so `go.sum` or `vs.Code` no longer look up `sum` or `Code`. Explicit `signature:` range and set clauses score the same on every query shape; multi-line prose had boosted them 5x. The snippet fixture ranks the file that contains the snippet first again, the #394 question with its second paragraph indented ranks the definition first, and a question mentioning `go.sum` ranks the checksum code above a `def sum` file. codetrans-contest, codetrans-dl, and codefeedback-st classify every multi-line query the same as before. 2 of 99 multi-line questions in a stackoverflow-qa sample, a quoted hard-wrapped problem statement and a SQL question with ASCII result tables,