fix(pcap): report a refused tool launch as an unavailable tool - #10553

Summary

A refused packet-tool launch could be reported as unreadable output, and matching an errno without its origin could blame TShark when the failure came from preparation or the Linux limiter. This change shares launch-refusal classification across pcap, apktool, GDB, ADB, and Java probes. Pcap uses the spawn error's path and syscall to attribute a direct refusal to the selected tool or limiter and supplies the corresponding repair guidance.

On Linux the tool runs through util-linux prlimit, which sets limits and then replaces itself with the tool. attributePcapLimitedExit (owned by PcapNativeBound, which selects and validates prlimit) reads prlimit's own err(3) diagnostics: prlimit: failed to execute ... with exit 127/126 is a missing or non-executable selected tool, any other prlimit: ... exit 1 is a limiter failure with the limiter repair, and everything else is the tool's own exit, classified exactly as without a limiter. A non-capture file therefore reports unsupported_target on Linux as on other platforms. Only a failure observed before any exit (stream collection failure) keeps the stage unknown. No new process authority or schema is introduced.

Validation

• Focused pcap, shared launch-classifier, and Ghidra Java-probe tests: 67 passed, including direct spawn failures and an actual child process whose unsuccessful exit leaves attribution unknown.
• npm run check:fast and formatting checks passed.
• The launch refusals were injected at the launcher boundary; no operating-system policy refusal or real Linux prlimit/TShark run was performed.

No issue was filed; the problem was found during an error-boundary audit.

• Review follow-up (maintainer decision: keep platforms consistent): reverted the Linux-only provider expectations to unsupported_target and added prlimit stand-in tests that run on every POSIX host (tool exit attributed to the tool, failed exec attributed to the selected tool, prlimit's own refusal attributed to the limiter). npm run test:focused -- tests/boundary/pcap/pcapCommand.test.ts — 15 passed; the 3 new tests fail on the previous head. Pre-push npm run check:fast passed. The real-prlimit path is covered by the Linux-only pcapProvider tests in CI.
• Review follow-up (launch identity): src/process/launchFailure.ts now owns which executable a launcher refused (executableLaunchRefusalOf): Node's spawn <path> errors and the Windows native launcher's executable-launch constraint with requestedPath. spawnOwnedProviderProcess gives errnos Node throws synchronously with a bare spawn syscall (ENOEXEC, ENOTDIR, ... — probed on Node 24.22.1/darwin) the same shape. Pcap no longer reads syscall/path itself. npm run test:focused -- src/process/launchFailure.test.ts tests/boundary/pcap/pcapCommand.test.ts src/process/ProviderProcess.launcherExit.test.ts src/windows/WindowsOwnedProcess.test.ts — 66 passed; the real-ENOEXEC and Windows-shaped pcap tests fail without the fix. npm run check:fast passed. Not run on a real Windows host.
• Review follow-up (Linux ENOEXEC): the real-process synchronous-refusal test now uses ENOTDIR (a path through a regular file), which every POSIX host refuses synchronously; ENOEXEC may instead be retried through /bin/sh on Linux. npm run test:focused -- tests/boundary/pcap/pcapCommand.test.ts — 17 passed; the test fails with nameSpawnedExecutable removed. Not run on Linux locally.

Author readiness

Human owner:

• I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
• I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
• I declare this PR ready for initial maintainer review.

Before merge

• This PR addresses a concrete problem or an agreed enhancement.
• Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
• The PR has one focused outcome and the title follows type(scope): outcome.
• Related issue is linked, or the reason for not linking one is stated above.
• Tests cover changed observable behavior and meaningful failure paths.
• Owning docs, contracts, and generated metadata are updated where needed.
• User-visible CLI/MCP changes include representative output.
• I checked the final diff for secrets, unrelated cleanup, and unsupported claims.