fix(launch_manager): enable ASSERT_DBG in integration tests

[hskang-amelia]

Summary

Follow-up to #579 (comment: #579 (comment)), which wired SCORE_LANGUAGE_FUTURECPP_ASSERT_LEVEL_DEBUG into unit tests via lm_cc_test but left integration tests untouched.

Integration tests link the production launch_manager daemon binary directly, so enabling the define there would mean enabling it on the same target that ships in production. Instead:

• Split the daemon's cc_binary into a launch_manager_binary macro (score/launch_manager/src/daemon/daemon.bzl) so a second target, launch_manager_debug_asserts, can share the same srcs/deps but add the debug-assert define, leaving the production launch_manager target untouched.
• Pointed the binaries list in each tests/integration/*/BUILD at the debug variant instead.
• Added a binary_renames option to integration_test() (backed by pkg_files's renames) so the packaged binary still shows up as launch_manager in the test environment — the test scripts hardcode that filename, and the debug-variant target has a different Bazel target name.

While verifying this locally in host mode, also found and fixed a pre-existing bug in tests/utils/plugins/localhost.py: LocalAsyncProcess.stop() sent SIGTERM to the whole process group so children launched under fakeroot would receive it, but fakeroot's /bin/sh wrapper traps EXIT/INT, not TERM — so the broadcast killed the wrapper itself before it could wait() for its child and relay the real exit code, making every host-mode integration test report LCM did not exit cleanly, it died with code -15 regardless of whether the daemon actually shut down cleanly. Fixed by signaling only the process(es) fakeroot launched.

Test plan

• bazel build --lockfile_mode=error --config=x86_64-linux //score/launch_manager/src/daemon/...
• bazel test --lockfile_mode=error --config=x86_64-linux //score/launch_manager/... (16/16 executed unit tests pass)
• bazel run //:format.check_Starlark_with_buildifier
• Ran the integration suite with --//config:integration_mode=host: 17/19 pass in an ad-hoc sandbox, and confirmed the remaining 2 are environment limitations rather than caused by this change:
  • complex_monitoring failed to build in the ad-hoc sandbox (Ubuntu, GLIBC 2.31): its component_complex_monitoring helper depends on //score/health_monitor's Rust FFI, which needs a newer GLIBC than that sandbox's rustc/ferrocene toolchain supports. Confirmed fixed by building the same target inside the repo's own ghcr.io/eclipse-score/devcontainer:v1.10.0 image (Ubuntu 24.04, GLIBC 2.39) — it builds and runs cleanly there.
  • sandbox_options fails in its own require_realtime_scheduling fixture (before the daemon binary even runs): chrt: failed to set pid 0's policy: Operation not permitted. This one is not resolved by the devcontainer alone: even inside ghcr.io/eclipse-score/devcontainer:v1.10.0 with the --cap-add=SYS_NICE from .devcontainer/devcontainer.json's runArgs, it still fails on a Docker host whose daemon hasn't been separately configured with real-time bandwidth — the container's cpu.rt_runtime_us cgroup value is 0 unless the host's /etc/docker/daemon.json sets {"cpu-rt-period": 1000000, "cpu-rt-runtime": 950000} and the daemon is restarted (exactly what the test's own failure message says), which is a host-level setting outside this repo's control.
• CI (opening as draft per the request on fix(launch_manager): enable ASSERT_DBG in unit tests #579, in case these — or other — failures look different under CI's Docker-mode integration tests)

[github-actions]

Documentation preview for this pull request is available at:
pr-591: https://eclipse-score.github.io/lifecycle/pr-591/