fix(freebsd): treat ${LOCALBASE}/bin as pkg-managed; resolve self via sysctl

[ocochard]

Follow-up to the closure of #1331. That PR was superseded by the runtime rework of install/update (#1566) and the KERN_PROC_PATHNAME self-path fix that landed on main. Two FreeBSD gaps remained, which @DeusData identified in the closing comment:

1. cli_external_manager_name() never recognised FreeBSD's package prefix

It matches only positive evidence (mise, Homebrew, nix, asdf, cargo). ${LOCALBASE}/bin (default /usr/local/bin) was not among them, so a ports/pkg install of cbm was still copied into ~/.local/bin and a shell rc was edited — exactly what externally-managed detection is meant to prevent.

Now ${LOCALBASE}/bin and /sbin are recognised on FreeBSD (#ifdef __FreeBSD__), so install skips the copy and update refuses and points at pkg upgrade codebase-memory-mcp.

LOCALBASE is configurable, so the FreeBSD port passes its real PREFIX via -DCBM_PKG_PREFIX and we honour it, falling back to the documented /usr/local default for a plain upstream build. --force-binary remains the escape hatch for anyone self-managing that prefix.

2. resolve_self_executable() in the HTTP server still read /proc/self/exe

FreeBSD does not mount /proc by default. Added a KERN_PROC_PATHNAME sysctl branch, mirroring cbm_detect_self_path() in cli.c.

Testing

cli_external_manager_detection_needs_positive_evidence_issue1566 updated: on FreeBSD ${LOCALBASE}/bin/cbm is now externally managed; a non-LOCALBASE prefix (/opt/local) is not.

Built and validated through the FreeBSD port (devel/codebase-memory-mcp) in a clean poudriere jail.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[ocochard]

One scoping note. This PR implements exactly the two items from the #1331 closing comment (prefix detection + the sysctl resolve_self_executable). While validating it through the FreeBSD port I hit a related gap that I deliberately left out of scope here:

After detection correctly skips the binary, agent configs still resolve through cbm_agent_installed_binary_path() / the install bin_target, both of which default to ~/.local/bin/codebase-memory-mcp — a path with no file on a pkg install. So install writes an mcp.json/hooks entry pointing at a nonexistent binary.

The FreeBSD port currently fixes this locally with two extra hunks: retarget cbm_agent_installed_binary_path() to ${PREFIX}/bin, and retarget bin_target to the OS-reported self_path when we skip. The clean upstream version would use the already-resolved runtime self_path rather than a compile-time prefix, but it needs a small signature change to cbm_agent_installed_binary_path().

Want me to fold that into this PR, or keep it as a separate follow-up? Happy to do either.

[ocochard]

Answering the two questions you raised in #1331 directly, since you asked me to own them rather than guess:

"Does a platform-conditional /usr/local/bin match match how ports actually behave?"
Yes. On FreeBSD, ${LOCALBASE} (default /usr/local) is where all third-party software lives — ports and pkg both install there, and pkg(8) owns every file under it. There is no separate "user prefix" convention the way ~/.local/bin is on Linux. So a binary running from ${LOCALBASE}/bin is, by construction, package-managed. Gating on #ifdef __FreeBSD__ is what keeps this from misfiring as you noted (/usr/local/bin is also Intel-Homebrew's prefix on macOS, and a legitimate --dir target elsewhere) — on those platforms the branch doesn't compile in.

"Is /usr/local/bin the only prefix worth matching, or should the check be broader?"
Two refinements over a bare /usr/local/bin:

1. ${LOCALBASE} is configurable. A user can set LOCALBASE=/opt/local (or a repo can be built with a non-default PREFIX). Hardcoding /usr/local in upstream would miss those. So the FreeBSD port passes its real PREFIX via -DCBM_PKG_PREFIX and this PR honors it, falling back to the documented /usr/local default for a plain upstream build. That keeps upstream correct for the 99% on default localbase while staying exact for the port.
2. /sbin as well as /bin. ${LOCALBASE}/sbin is a valid install target for daemons; matched both for completeness (harmless for this CLI, correct in general).

--force-binary remains the escape hatch for anyone who deliberately self-manages that prefix.

---

CI note: the one red check (test-unix (macos-15-intel)) is lock_registry_absolute_deadline_survives_repeated_wakes failing on ASSERT(tail_queued) — a thread-timing test unrelated to this diff (I touch no lock-registry code), which passed on macos-14, all Linux/Windows shards, tsan and msan. Looks like a runner-load flake; a re-run should clear it (I don't have rerun rights on the repo).