fix(picker): cache apropos result to speed up :Telescope man_pages

[delphinus]

Description

:Telescope man_pages uses output from the command: apropos. This is too slow command to use for this.

~ ❯❯❯ hyperfine -w 5 -N 'apropos .'
Benchmark 1: apropos .
  Time (mean ± σ):      1.457 s ±  0.082 s    [User: 0.386 s, System: 1.004 s]
  Range (min … max):    1.317 s …  1.556 s    10 runs

This patch caches the output and reuse it until it becomes stale. Now it detects it is “stale” if the cache file mtime is older than 86400s before.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

I confirmed it works on macOS and Linux. But I didn't write unit tests.

• :Telescope man_pages opens fast because of cache
• Deleted cache, and :Telescope man_pages opens slowly again

Configuration:

• Neovim version (nvim --version): NVIM v0.11.0-dev-4649+g6719276040-Homebrew
• Operating system and version: macOS Sequoia 15.1.1

Checklist:

• My code follows the style guidelines of this project (stylua)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (lua annotations)

[Conni2461]

I dont see a reason for caching ... 1s is not that slow. This just adds overhead for one specific picker

[delphinus]

∆When I tested clean-installed Ubuntu, this takes <10ms and :Telescope man_pages makes no lags. In comparison with standard Linux, macOS has huge amount of man pages in default settings, so users (I) feel annoyance with using it.

As another suggestion, it is good if a cacheable finder exists in telescope. It may cache results of the same command execution. I think it is useful when users expect the same results from async_oneshot_finder. Can you accept such finder instead of adding this patch?

[clason]

@delphinus sorry for neglecting this PR. I agree that a generic cache would be worth it, but that is blocked by the long-overdue architecture review.

The man page finder is also particularly slow, so special-casing this may make sense in the short term. Could you please

1. rebase on latest master
2. replace plenary Path with vim.fs calls
3. consider invalidation strategies (e.g., if users install software outside a running Neovim instance).

[delphinus]

I created a suceeded PR: #3616. So close this.