Add interpreter-wide R help search support

[kv9898]

R backend support for the Help search and autocomplete UI in posit-dev/positron#15923, addressing posit-dev/positron#422.

Changes

• Add search_help(query, search_id) while preserving native utils::help.search() matching and result rendering across installed packages.
• Add query-filtered, ranked get_help_topics(query, limit) responses, bounded to 1–50 suggestions, with package-qualified topic targets.
• Refresh cached topic metadata when the installed-library metadata changes. Index construction remains synchronous.
• Echo the optional UI search ID in show_help so the frontend can ignore obsolete results. Scope the ID to the request and restore it on exit, including errors; ordinary console help remains untagged.
• Update generated Help protocol bindings and cover bounded suggestions, cache freshness, native search, and navigation correlation. The correlation test tolerates interleaving between shell status and comm delivery.

Scope and integration

posit-dev/positron#4484 (reloading search results at the same URL) is acknowledged but deliberately left to the Positron team.

After this merges, Positron needs to adopt the resulting upstream Ark version through its normal update process. The companion Positron PR intentionally contains no Ark submodule pointer change.

Validation

• Rust formatting and cargo check passed locally.
• The selected Help-related tests passed locally, including the navigation-correlation test rerun after correcting its cross-thread message-order assumption.
• Manually verified R searches and package-qualified topic selection in Positron.
• The previous CI run passed all seven Linux test configurations; macOS/Windows exposed the correlation-test ordering assumption, now corrected. Platform CI is rerunning.

The earlier local KEYWORDS.db blocker was resolved by supplying the correct R documentation/share/include paths; it is no longer blocking integration tests.

[kv9898]

@juliasilge @eitsupi, I have an optional r-documentation-rs prototype available for review: kv9898#6. Thanks again for suggesting the shared reader infrastructure.

It is a draft PR in my fork, targeting feature-help (the branch behind #1401), so the diff shows only the reader adoption. It uses rd-rds 0.4.0 to read installed Meta/hsearch.rds aliases, retains native help.search() matching/rendering and the existing Help protocol, and falls back to R for unsupported metadata. It can be considered separately without making it a prerequisite for posit-dev/positron#15923 or Ark #1401.

I also benchmarked the current R-only implementation (e9e36753) against the prototype (c8d64da6):

Backend operation	R-only	Rust-reader prototype
First-use suggestions	495 ms	350 ms
Cached suggestions, per call	3.13 ms	3.07 ms
Fresh search without prior suggestions	646 ms	833 ms
First search after suggestions	167 ms	553 ms
Repeated search	167 ms	167 ms

Method: Linux laptop (Core Ultra 9 285H), R 4.6.1, 340 installed package entries; optimized build, median of 15 samples per implementation/scenario. Suggestions used plot with limit 50; searches used linear model. Cached-suggestion samples averaged 30 calls. To reduce the timing drift observed in separate runs, the main comparison alternated the original and prototype R backend definitions in the same optimized, reader-capable Ark process. The original definition uses the R-only path; the prototype calls the compiled Rust reader. Each sample started with a fresh application cache, with the relevant caches primed outside timing for warm scenarios. The filesystem cache was warm. This measures backend work, excluding startup, frontend debounce, RPC transport, HTML rendering, and waiting behind user code.

The result is a tradeoff: about 29% faster first-use suggestions, but slower initial searches. The baseline prepares R’s native search database while constructing suggestions; the prototype reads aliases separately, so the first submitted search pays the deferred native-database build. A fresh submitted search pays for both paths. Cached suggestions and repeated searches were essentially unchanged. These are measurements of this prototype on one machine, not a general performance claim about the library.

The benchmark verified identical bounded suggestions and that the Rust reader succeeded without taking the fallback. The prototype also passed 25 targeted Help tests and Clippy. Indexing still runs synchronously; this draft does not yet implement the background worker discussed earlier. I would welcome feedback on the reader adapter and index lifecycle before taking that further. The existing upstream PRs remain independent of this experiment.