feat(e2e): three-container robot topology with dc-uploader as its own container

[Minipada]

Summary

Completes #440's split-deployment scenario 2 (the last of the three components): dc-ros, vector and dc-uploader now run as three separate Compose-managed containers, building on #445 (dc-ros + vector split) and #446 (dc_uploader extracted into its own process).

• compose.split.yaml gains a dc-uploader service running the same image as dc-ros under a dedicated entrypoint (entrypoint_uploader.sh, which execs the installed dc_uploader binary directly — no ros2 launch), configured entirely by DC_UPLOADER_* environment variables. No depends_on with either sibling container. dc-ros launches with a new run_uploader:=false launch argument (dc_bringup.launch.py) so it no longer also spawns its own dc_uploader subprocess.
• Volumes stay scoped to their owner (Three-container robot topology with the Uploader as its own container #447's acceptance criteria): the intent queue + Files volume is shared between dc-ros (writer) and dc-uploader (reader) only; the rendered-config and buffer volumes stay scoped to dc-ros/vector as before, untouched by dc-uploader.
• Object-storage credentials live only in dc-uploader's environment. e2e_split_params.yaml's rustfs destination no longer carries access_key_id/secret_access_key at all — the Bridge only needs the bucket name to write upload intents, never the keys — so those credentials never reach the ROS container.
• dc_bridge gains shipper.bind_host, decoupling the address Vector's fluent source binds to from vector_forward_host (where the Bridge itself connects). Found while getting the harness to actually run: Vector's fluent source rejects a hostname for its own listen address ("data did not match any variant of untagged enum FluentModeDe"), so reusing vector_forward_host for both roles — fine when both are 127.0.0.1 — breaks once the Shipper listens inside its own container reached by DNS name. Defaults to vector_forward_host, so every deployment that doesn't set it is unchanged.
• run_split.sh fixes two more pre-existing bugs that blocked it from ever completing a real run (neither ever exercised before — run_split.sh's own full execution was left unchecked in Two-container split: ROS stack and Shipper under Compose #445's test plan): the RustFS reachability probe needs --entrypoint python3 (without it, dc-e2e's own ENTRYPOINT swallows the probe args as extra ros2 launch arguments and the container always exits non-zero, regardless of RustFS's actual reachability), and the bucket-creation step needs the compose service name (rustfs), not the container_name, since aws-cli's endpoint validation rejects the latter's underscores as an invalid hostname. It also now starts dc-uploader alongside dc-ros and restarts it independently in steady state, directly exercising Three-container robot topology with the Uploader as its own container #447's per-container restart requirement — placed in steady state rather than layered onto the outage/dc-ros-restart window, since restarting two containers back to back was found to add enough jitter to the DDS→Shipper handoff to occasionally cost a Record outside the harness's per-restart kill-point tolerance.

Test plan

• prek run --all-files --skip build-doc — all hooks pass
• bash -n + shellcheck clean on the touched/new shell scripts
• compose.split.yaml / e2e_split_params.yaml parse as valid YAML
• Full workspace rebuild + colcon test: 0 failures (TEST_RESULT=0)
• tools/e2e/scripts/run_split.sh executed end to end against the built image, three times: the first surfaced the two pre-existing harness bugs above (fixed), the second surfaced real record loss from the double-restart timing (fixed by decoupling the restarts), the last two passed cleanly — ZERO-LOSS VERIFICATION PASSED (22 sources checked, 0 violations)
• Confirmed during those runs: dc-ros recovers on its own when vector starts late (no restart needed); dc-uploader restarts independently without needing dc-ros/vector restarted; the durable upload intent queue drains to empty after the outage+restart; credentials are absent from dc-ros's params file and rendered config

Closes #447

[codecov]

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.46%. Comparing base (5c650d9) to head (cf127a2).

Files with missing lines	Patch %	Lines
dc_bridge/src/bridge_node.cpp	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            jazzy     #460      +/-   ##
==========================================
+ Coverage   71.45%   71.46%   +0.01%     
==========================================
  Files         124      124              
  Lines        7562     7563       +1     
==========================================
+ Hits         5403     5404       +1     
  Misses       2159     2159              

Flag	Coverage Δ
cpp-jazzy	71.46% <0.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.