feat(state): add coordinator in-memory shared KV store with TTL and delete

[Bhanudahiyaa]

Closes #1456

Problem

Project #3 needs a first usable shared-state backend. Contract-only/no-op handling is not enough to exercise real multi-daemon state flows.

Why this matters

This PR introduces a concrete coordinator-side backend with minimal scope:

• establishes real runtime behavior for shared state operations,
• enables incremental testing and iteration before replication/failover,
• keeps risk low by staying in-memory and coordinator-local.

What changed

1) New coordinator shared-state store

• Added SharedStateStore in binaries/coordinator/src/shared_state.rs
• In-memory KV keyed by (namespace, key)
• Supports:
  • get(namespace, key)
  • set(namespace, key, value, ttl_ms)
  • delete(namespace, key)

2) TTL semantics

• state_set supports optional ttl_ms
• None => non-expiring key
• Expired keys are treated as missing and cleaned up lazily on read
• Validation:
  • ttl_ms == 0 is rejected
  • oversized TTL is rejected
  • empty namespace/key is rejected

3) RPC contract updates (libraries/message)

• Added request types:
  • StateGetRequest
  • StateSetRequest (includes ttl_ms)
  • StateDeleteRequest
• Extended CoordinatorNotify service with:
  • state_get
  • state_set
  • state_delete

4) Coordinator wiring

• Added shared_state field to CoordinatorState
• Initialized in coordinator bootstrap path
• Implemented RPC handlers in CoordinatorNotifyServer:
  • get reads from in-memory store
  • set writes with TTL
  • delete removes key and reports whether it existed

5) Integration-style RPC test

• Added test in binaries/coordinator/src/listener.rs:
  • set -> get -> delete -> get(missing)
  • set with TTL -> wait -> get(expired)

Design notes / tradeoffs

• Backend is intentionally in-memory only for this step.
• TTL cleanup is lazy-on-read to keep complexity minimal.
• This PR is scoped to coordinator ownership of state; no replication/persistence yet.

Validation

• cargo fmt --all
• cargo test -p dora-coordinator listener::tests -- --nocapture
• cargo test -p dora-coordinator state_set_get_delete_and_ttl_over_rpc -- --nocapture
• cargo build -p dora-daemon
• cargo clippy -p dora-coordinator --all-targets

(Existing unrelated workspace warnings remain unchanged.)

———

[Bhanudahiyaa]

Hi @phil-opp , quick question on the failing Ubuntu CLI test.

From the logs, it looks like the failure might be coming from the error propagation example (the simulated failure path), rather than the shared state changes introduced here.

Since this PR only touches coordinator state + RPC handling, I wanted to confirm:

• is this test expected to be flaky / environment-sensitive?
• or could the new coordinator state initialization be indirectly affecting CLI test behavior?

Happy to dig deeper, just wanted to check before chasing the wrong direction.