[capi] Scan the data access widths while warming

[gmh5225]

Summary

A C view reads the widths of the image's data accesses (Session::dataAccessWidths), which a scan of every function's instructions finds. The session keeps the result while the functions' extents stay. The first C view of a session paid for that scan, even when warming had already prepared the function. On the corpus the scan is most of the first decompile after opening: 40–150 ms against a few ms for every later one.

neverd_warm_functions_json now makes the scan in its first call, where nothing waits on it, exactly as that first view would. The session keeps it as before:

• A view whose function list has changed scans again.
• Reloads, edits and policy changes still drop it.

The API comment and the architecture guide say so.

Measurements

Release build, NEVERD_THREADS=4, pinned to 4 CPUs. Each run opened with warming, waited for it to finish, and then decompiled the image's first five functions. Two runs per side, alternating.

Binary	First decompile, dev	First decompile, this change
Rust Windows DLL	51.8 / 48.7 ms	11.2 / 14.0 ms
Rust x86_64 Linux probe	112.5 / 112.8 ms	8.6 / 8.3 ms
Go 1.21 linux-amd64 stripped	178.0 / 174.3 ms	25.3 / 18.6 ms

Later decompiles and the time warming takes are unchanged within noise. Decompiling every function of the probe (565) and the DLL (338) gives identical sources either way.

Tests

• New SessionCAPITest.WarmingScansTheDataAccessWidthsTheFirstViewReads:
  • After warming, the session holds the widths.
  • The first decompile reads that same storage.
  • Its source equals a session's without warming.
• NeverDSessionCAPITests 173/173, NeverDPipelineOutcomeTests 42/42 and the worker tests with the real engine (ctest -R NeverDWorker, 36/36) pass.
• After merging the latest dev: NeverDSessionCAPITests 174/174.
• scripts/check_clang_format.py passes. scripts/check_docs_i18n.py fails on dev already, on docs/zh-CN/process-emulation.md (missing token revents), a file this change does not touch.