fix(netbsd): add NetBSD support to daemon IPC and runtime

[cmeerw]

Extend Linux codepaths in runtime.c to also cover NetBSD, and add NetBSD-specific peer PID retrieval via LOCAL_PEEREID in ipc.c.

[DeusData]

Thank you for this — it is a careful, minimal port, and I want to tell you plainly where it stands rather than leaving it silent.

The code review came back clean, and I checked the part that would worry me most. The runtime.c changes are purely || defined(__NetBSD__) added to conditionals that already existed, so they are preprocessor-inert on Linux, macOS and Windows. The new ipc.c branch is guarded on SOL_LOCAL && LOCAL_PEEREID, which are NetBSD-only, and it sits after the Linux SO_PEERCRED and macOS LOCAL_PEERPID branches — so it is unreachable on the three platforms we ship. I verified that specifically, because a widened #ifdef quietly capturing an existing platform is the failure mode that would make a 16-line port dangerous. It does not happen here.

The NetBSD peer-credential logic itself reads correctly — unp_pid with a length check, failing closed to 0 rather than open.

What is holding it is a policy question, not your code. Merging means the project claims NetBSD support, and we have no NetBSD CI leg — so this path would be contributor-verified only, indefinitely. That is a maintainer decision about which platforms we are willing to stand behind without automated coverage, and I have put it in front of him rather than deciding it myself. I would rather give you a real answer than a quiet merge that leaves you as the sole guarantor of a platform forever.

Two things that would help whichever way it goes:

• A line in the docs stating NetBSD is best-effort and untested by CI would make the commitment honest and explicit.
• Worth noting in that same place: the shared path relies on /proc/<pid>/exe, which needs procfs mounted and that is not a NetBSD default. It degrades fail-closed — acquire simply returns false — so it is not unsafe, but a NetBSD user hitting it would otherwise have no idea why.

One practical heads-up: #1138 also edits the same #elif defined(__linux__) chains in runtime.c for a FreeBSD port, so whichever of the two moves first will conflict the other. Not something you need to act on now.

Thanks for the patience, and for keeping the change as small as it is — that is a large part of why the review was straightforward.