[D070] [FEAT] [ORACLE] Publish probe-derived signals on-chain (extend publisher beyond outcome_log)

[ezedike-evan]

Context

ROADMAP.md Horizon 1: "Write probe-derived data to the testnet contract on a schedule."

The publisher cron is live (.github/workflows/reputation-cron.yml "Publisher tick" step → POST /api/publisher/tick → runBatch under lock, verified against the deployed testnet contract). But packages/publisher/src/batch.ts reads exclusively from outcome_log (execution outcomes). The probe-derived signals the roadmap names — uptime, quote latency (p50/p95), quote drift — are computed by lib/reputation/probe.ts and stored in probe_samples, but never reach the contract. The cron currently publishes the wrong data class for this roadmap bullet.

Requirements

1. Extend the publisher batch to aggregate per-anchor probe-derived signals (uptime ratio, latency p50/p95, drift flag counts) over a configurable window from the probe_samples store.
2. Include these signals in the on-chain payload alongside execution outcomes; version the payload shape so the consumer crate can distinguish.
3. Handle the empty-data case gracefully (probes not yet running — see [D007] [FEAT] [OPS] Scheduler/cron to run all anchor probes continuously lumenwatch/stellar-intel#7 for probe scheduling): publish execution outcomes only, log that probe signals were skipped.
4. Tests: batch aggregation from fixture probe samples; payload shape; empty-probe-data path.

Dependencies

• Probe runner activation (tracked as [D007] [FEAT] [OPS] Scheduler/cron to run all anchor probes continuously lumenwatch/stellar-intel#7, D007) — this issue is still implementable and testable against fixture data before that lands.

Estimated file changes

packages/publisher/src/batch.ts, lib/reputation/store.ts (query helper if missing), packages/publisher tests.

Refs: ROADMAP.md line 37 (H1 bullet d). Part of the D0xx Horizon 1 workstream (new: D070).

[ezedike-evan]

Three hard prerequisites, all now filed:

1. [BUG] [REPUTATION] Probe sweep throws in production — the 90-day clock has never started #906 — probe persistence throws in production, so there are no probe-derived signals to publish yet.
2. [SECURITY] Three unauthenticated write entrypoints on the reputation oracle #907 — set_corridor_metrics, the natural carrier for these signals, is unauthenticated. Publishing through it before the auth fix productionises a public write path into the oracle. The fix is a breaking ABI change, so it must land first, not after.
3. [BUG] [PUBLISHER] N outcome rows are stamped with a single tx hash — duplicate republish on partial failure #909 — the publisher stamps N rows with one tx hash and re-publishes the whole batch after a partial failure. Pushing more data through that pipe first multiplies the duplicates.

Also relevant: add_volume_savings and set_corridor_metrics already exist as carriers, so this is largely wiring once the three above are done. Sequencing behind them.