fix(daemon): let a shipped build relocate the rendezvous via CBM_RUNTIME_DIR

[DeusData]

The blocker

The daemon/CLI rendezvous directory is created under %LOCALAPPDATA% (Windows) or
/tmp — /private/tmp on macOS — and every ancestor of it must pass the
private-directory walk. When that ancestry is not acceptable, every invocation
fails, config list included, so the settings surface cannot be reached either:

codebase-memory-mcp: secure daemon endpoint could not be created

There was no way to move it in a shipped build. The only relocation hook,
CBM_TEST_DAEMON_RUNTIME_PARENT, is compiled out unless CBM_ENABLE_TEST_SEAMS is
defined, so a test build starts while the product build does not. CBM_CACHE_DIR
is no help: it moves the cache and never the rendezvous.

#1623 narrowed the Windows side by admitting AppContainer package and capability SIDs
on ancestors, and named the remainder explicitly — a live local group, Authenticated Users inherited from a secondary volume root, and orphaned unresolvable SIDs still
refuse, and "those need CBM_RUNTIME_DIR or a separate change". This is that change.
#1621 is the POSIX shape of the same dead end.

What this does

CBM_RUNTIME_DIR names the parent directory the rendezvous is created under
(cbm-daemon-<uid> on POSIX, cbm-daemon-<key> on Windows).

It does not relax the check. The directory it names goes through exactly the same
validation as the default — ancestors owned by you or root, not world-writable, no
allow-ACL; the rendezvous directory itself still forced to owner-only — and a value
that fails is refused rather than silently replaced by the default. The operator
only chooses an ancestry that passes. cbm_safe_getenv never truncates, so no half of
an over-long value can become a runtime parent.

The override is resolved in cbm_daemon_bootstrap_endpoint_new(), the one function
every product endpoint goes through — daemon, MCP client, local CLI, index worker, and
the install/update/uninstall activation path in src/cli/cli.c. Resolving it there
rather than at the call sites is deliberate: no call site can silently keep the
default, and it is outside every CBM_ENABLE_TEST_SEAMS guard, so the shipped build
has it. An explicit parent still wins, so the compile-time test seam and the lifecycle
guards' isolated namespace behave exactly as before. The detached daemon inherits the
value with the rest of its environment.

Credit: approach and variable name from #1576 by @tmonestudio, resolved one layer
lower so the activation path is covered too — Co-Authored-By in the commit.

Test

daemon_bootstrap_runtime_dir_env_relocates_rendezvous in
tests/test_daemon_bootstrap.c (registered in SUITE(daemon_bootstrap)) asserts three
things in one process: the rendezvous lands under the named directory; an explicit
parent still beats the environment; and a named parent that cannot pass validation
yields no endpoint rather than a quiet fall back to the default. It restores the
environment before asserting, so a failed assertion cannot leak CBM_RUNTIME_DIR into
later suites in the same process.

Revert-check — production hunk reverted, test rebuilt and rerun:

daemon_bootstrap_runtime_dir_env_relocates_rendezvous    FAIL tests/test_daemon_bootstrap.c:444:
  ASSERT(bootstrap_path_has_parent(relocated_runtime, canonical_override))
24 passed, 1 failed

With the fix in place: 25 passed for daemon_bootstrap, and 490 passed / 0 failed
/ 0 skipped across daemon_bootstrap daemon_ipc daemon cli daemon_runtime daemon_application daemon_frontend daemon_version activation_transaction.
make -f Makefile.cbm lint-ci clean.

What is NOT verified here

Local verification was macOS only. Much of the Windows path — win_parent_valid,
win_private_directory_tree_secure, the DACL walk this is meant to route around — is
compiled out on macOS, so a clean local build proves nothing about it. What the local
run does prove is that the override reaches cbm_daemon_ipc_endpoint_new(), which is
the same parameter the Windows implementation already substitutes for
win_default_runtime_parent(). The Windows behaviour needs the CI leg, and ideally a
confirmation from a reporter on an affected machine.

Still open in #1574 (not in this PR)

Two of the reporter's three asks are unaddressed on purpose, to keep this to one claim:

1. Name the offending path in the endpoint error. Still missing — and while
   verifying this I found the existing detail names the wrong component:
   private_directory_tree_open() runs posix_directory_parent_secure(current_fd) on
   the parent but formats the message with component, the child about to be
   entered. So /private/tmp/cbm-daemon-501: ancestor 'cbm-daemon-501' is not a usable private-directory parent (CBM_CACHE_DIR ignored; daemon still requires /private/tmp/cbm-daemon-<uid> on macOS #1621) actually means /private/tmp failed, and
   …/.cache/codebase-memory-mcp: ancestor '.cache' … (No such xattr: com.apple.quarantine #1537) actually means
   /Users/<user> failed. Both reporters were pointed at a directory that was not
   the one refusing. That is a one-line diagnostic fix but a separate claim.
2. Document the required DACL shape. Partially covered by the new
   docs/CONFIGURATION.md section, which states the rule the walk applies; the
   Windows-specific DACL shape is not spelled out.

Self-healing a stale runtime directory already exists and needed no change:
private_directory_tree_open() fchmods the final component to 0700 and clears its
extended ACL when the owner is the current user, and
daemon_ipc_posix_private_directory_hardens_existing_cache_root already covers it.