Fixed

Installer npcap exit-dialog prompt reconciled with the docs (slice S060)

The Windows installer's exit-dialog npcap prompt no longer reads as an unconditional requirement to a user who already installed the capture driver. It now detects, via core WiX FileSearches under [System64Folder], the same two markers fragcap doctor probes: npcap's own driver copy (System32\Npcap\wpcap.dll) and the WinPcap-API-mode copy the live backend loads (System32\wpcap.dll). The "open the npcap download page" option is pre-checked unless both are present. On a machine that installed npcap in WinPcap-API mode as the prerequisite (through Wireshark), the option is shown unchecked so the user can click Finish straight through; on a machine without npcap, with npcap but no WinPcap-API mode, or with only a stray legacy WinPcap copy, the option is pre-checked and Finish opens the vendor's page, matching what doctor reports. The label is reworded to name npcap as the capture driver and frame the page as for a user who does not already have it, rather than asserting it is "required before capturing traffic" (issue #133).

The policy is unchanged: fragcap still downloads, bundles, and installs no npcap; the checkbox only opens the vendor's page, and only when left checked. This is a presentation fix. No new WiX extension is introduced (FileSearch, AppSearch, and SetProperty are core WiX 3), and there is no code, dependency, or Cargo.lock change. The getting-started guide and the specification's distribution note are reconciled with the conditional behavior.

fragcap doctor no longer aborts on a machine where the capture DLL cannot be loaded. The real-interface enumeration reaches the delay-loaded wpcap.dll, and it was called before that DLL's presence was established, so the first call raised a delay-load exception (0xC06D007E) and the process exited before doctor could report the very condition it was checking for. This defeated the delay-load design, whose whole purpose is to let doctor run and say what to install on exactly that machine. doctor now probes the live backend only when the WinPcap-API-compatible wpcap.dll the backend actually delay-loads (the System32 copy, installed by npcap's WinPcap API compatibility option) is present; when it is absent nothing is attempted and the npcap and WinPcap-API checks carry the remediation, so doctor runs to its normal not-ready exit instead of crashing. This covers both a machine with no npcap at all and npcap installed without the compatibility option. It surfaced only in the release build (features live, socket-table, etw) run without a loadable wpcap.dll, which the default test build does not exercise.