backend: cronix-backend-echo reference plugin (validates the plugin protocol)

[awbx]

Deliverable: a trivial out-of-tree backend plugin — cronix-backend-echo — that exercises every RPC defined by the plugin protocol (#26) and reconciles to an in-memory map.

Dependency: blocked on #26 (plugin protocol RFC promotion to D-NNN). Cannot land until the protocol contract is locked.

Why this matters

Plugin protocols are notoriously expensive to redesign once people start shipping against them. The only reliable way to catch design mistakes is to write a real plugin against the protocol while it is still a draft, then iterate on the proto until the plugin compiles cleanly and passes the conformance vectors.

The echo plugin is the smallest possible plugin that touches every part of the contract — handshake, lifecycle, every RPC method, every error path. It is to the plugin protocol what a "hello world" is to a language: not useful in production, but the fastest way to find the rough edges.

Behavior

• Reconciles to an in-memory map[string]Entry, persisted to a JSON file at $HOME/.cache/cronix-echo/state.json for inspection between invocations
• Every RPC writes a structured log line to stderr showing {rpc_name, request_summary, response_summary, duration_ms} — primary debugging value
• Read returns the persisted map
• Plan diffs the requested manifest against the map
• Apply writes the manifest into the map
• Drift re-reads and compares
• Prune removes entries not present in the manifest
• Adopt claims a manually-inserted (no marker) entry by tagging it owned in the in-memory map
• VerifyOwnership reports back the four states from reconciler: cronix verify-ownership — operator-side audit of owned entries #20 (ok / adopted / abandoned / tampered)

Why these specific RPCs

This is exactly the surface area of the Backend interface. The echo plugin's job is to exercise the protocol, not to do something useful. Anything the protocol can express, the echo plugin must accept and round-trip; anything the protocol cannot express is a protocol bug that this plugin will expose.

Acceptance criteria

• Repository: github.com/awbx/cronix-backend-echo (separate from the core repo — proves out-of-tree integration)
• Binary: cronix-backend-echo matching the discovery convention from spec: plugin protocol for out-of-tree backends (RFC — v2.0) #26
• Implements the full BackendPlugin gRPC service from spec/plugin/backend.proto
• Passes the conformance vectors via the runner from spec: extract spec/conformance/ runner — language-neutral harness #6 in plugin-target mode
• Apache 2.0 licensed, DCO-signed commits (mirrors core repo standards)
• README documents: install path, how to run against a sample manifest, what each RPC logs
• CI runs the conformance suite on every PR
• Linked from the curated plugin list at docs-site/content/community/plugins.md (docs: backend coverage strategy — tiering, criteria, community-facing roadmap #22) as "reference implementation — start here if writing your own"

Stretch — companion tooling

If the echo plugin reveals the protocol is awkward to implement, the design feedback goes back into #26 as comments / additional RPCs / removed RPCs. Document any iteration explicitly in the D-NNN decision log so future plugin authors understand which design choices have been validated against a real plugin and which were guesses.

Out of scope

• Persistence beyond a local JSON file
• Multi-app or multi-host coordination
• HTTP firing — the echo plugin is a backend, not a fire mechanism. (Multi-strategy fire is spec: fire strategies beyond HTTP (RFC — manifest v2 wire-contract change) #25; that's a separate concern.)