[codex] prototype codemapd sidecar using sockd

[JordanCoin]

Summary

This opens the first real sockd adoption inside codemap.

What is in this prototype:

• add a Rust codemapd sidecar built on sockd::Daemon
• add a pure-Go sockd frame client for hook/context/serve reads
• prefer socket-backed cached state where available, with fallback to .codemap/state.json
• start codemapd during hook sessions and shut it down on session stop when the sidecar is discoverable

This is intentionally the mirrored-state variant for the first pass: the Go watch daemon still owns .codemap/state.json, and codemapd caches and serves slices of that state over the socket.

What Works Now

• real library adoption: codemapd is built on sockd, not a reimplementation of the protocol
• no cgo requirement: the Go side speaks the frame protocol directly
• backward compatibility: reads still fall back to state.json if the daemon is unavailable
• local validation is green:
  • go test ./...
  • cargo test in codemapd
  • smoke test with session-start, pre-edit, and session-stop

Current Limits

• codemapd currently depends on a local sibling sockd checkout
• sidecar discovery is currently CODEMAPD_BIN or a sibling codemapd binary
• this does not yet change release packaging or installation flows
• Windows remains effectively unsupported for this path until sockd has a Windows transport story
• the watch daemon is still the source of truth; this is not the final end-state architecture yet

Checklist For Full Implementation

• replace the local sockd path dependency with the publish/install strategy we actually want
• define the packaged install and discovery story for codemapd
• wire codemapd into release artifacts and installer flows
• add focused tests for socket-backed reads and daemon lifecycle behavior from the Go side
• decide which command paths should auto-start codemapd vs remain opportunistic
• measure hook latency before and after this path and document the delta
• decide whether to keep the mirrored-state variant or move to a direct worker-backed daemon model
• define the Windows behavior explicitly, even if that means feature-gating this path for now