Initialize `roxyd` base code structure

[sae-bom]

Based on #496

Initialize the codebase for roxyd inside the existing crate. It includes entrypoints, config, logging, and review-protocol connection skeletons, and dual-path coexistence with the legacy implementation, but it does not port any existing handler logic yet.

The structure should be friendly to AI coding agents (small, focused modules; clear naming; minimal hidden coupling).

---

Tasks

1. Add a new binary target inside the existing crate

• Add a new binary entrypoint (e.g. src/bin/roxyd.rs)
• Add a feature flag that allows selecting between the legacy implementation and the new roxyd implementation.
• Define a minimal main that:
  • Parse and load CLI args and/or config path.
  • Initialize tracing
  • Start the main async runtime (e.g. via #[tokio::main]).
• Add a short README section that explains:
  • This is a new implementation path that coexists with the legacy one.
  • Existing code must not be removed while legacy mode is still in use.
  • Current limitations (skeleton only; no real handlers yet).

2. Define configuration for the QUIC/mTLS connection

• Add config fields for QUIC/mTLS connection to Manager
  • QUIC endpoint / Manager address.
  • mTLS / certificate paths or references.
  • Optional: per-node identity (AgentInfo) fields.

3. Set up review-protocol client skeleton

• Add a review_protocol integration module that exposes a function like run_connection_loop(config: &Config) -> Result<()> that will:
  • Establish QUIC/mTLS connection.
  • Perform the initial handshake.
  • Enter a request/response loop.
  • Receive and route RequestCodes.
• For now, do not implement real handlers:
  • Provide a generic handle_request stub that logs the RequestCode and returns a dummy result (e.g. unimplemented or a static error).
  • Add TODO comments where individual handler families will be plugged in later.

4. Internal module layout for handlers

• Create a directory structure like:

  • roxyd/handlers/
    • service_control.rs
    • hostname.rs
    • ntp.rs
    • syslog.rs
    • power.rs
    • observation.rs
    • (… follow predefined design doc)

• In each handler module:

  • Define public function signatures only.
  • Leave bodies as todo!() or simple unimplemented!() to be filled in by follow-up issues.

5. Logging, tracing, and error types

• Reuse the crate’s existing tracing subscriber setup instead of introducing a new logging framework.
• Plug in tracing with:
  • Basic subscriber setup in main.
  • Startup and shutdown.
  • Connection lifecycle (connect/reconnect).
  • Incoming RequestCode + handler dispatch.
• Ensure logs are compatible with the existing stack:
  • Use existing log formats / levels where possible.
  • Avoid introducing a different logging framework.

6. Tests and examples

• Add at least one example unit test or component test.
• Add an example config file in examples/ or configs/ to illustrate how to run the new binary.

7. CI / build integration

• Update the workspace and CI so that:
  • The new roxyd binary target is included in cargo build / cargo test.
  • Existing lint, fmt, and coverage jobs run against the new code.
• Verify that CI still passes with:
  • Legacy-only configuration.
  • New binary enabled but with stub handlers.

---

Acceptance Criteria

• New binary target compiles and passes tests with stub handlers only.
• QUIC/mTLS + review-protocol skeleton is in place (handshake + request loop).
• Old implementation remains fully functional and is still the only path used in production code; switching logic is isolated behind feature flags.
• CI is green: build, lint, tests.
• The module layout makes it clear where follow-up issues should plug in handler logic, observability, and deployment specifics.