relay: accept HTTP agent observer frames (draft handoff)

[cloud-on-prem]

Summary

Agent runtimes that only speak HTTP can now publish NIP-AO observer frames (kind 24200) through POST /events, not just over WebSocket.

• The WebSocket validation for observer frames is moved into a transport-neutral core in handlers/ingest.rs. Both transports run the same signature, freshness (±300 s), envelope and agent-owner checks.
• Accepted frames fan out only to the owner's live subscriptions. They are never persisted or queryable, and they no longer count toward buzz_events_stored_total.
• HTTP frames count against the existing API-call quota. Both the per-agent observer limit and the API-call quota return 429, so callers can drop or back off.
• A WebSocket freshness rejection still returns OK false with the same message. It is not counted as a relay error.
• Conformance traces gain a dedicated AcceptEphemeral action (schema v2) instead of reusing WriteInsertGlobal.
• docs/nips/NIP-AO.md now documents the HTTP bridge behaviour.

Kind 24200 is deliberately not exempt from the HTTP API quota (see #7736). The expected volume is low, so we'll measure 429s before considering an exemption or batching.

Known limitation

The agent → owner mapping is only recorded when an agent authenticates through the x-auth-tag fallback. An agent that was added directly as a relay member has no recorded owner, so its frames are rejected. test_http_direct_relay_member_observer_frame_hits_known_owner_recording_gap pins this behaviour. Fixing it is out of scope here.

Testing

• Pre-push hooks pass: file-size check, fmt, clippy, Rust unit tests (rust-tests), Tauri checks.
• New relay e2e tests in e2e_relay.rs: test_http_agent_observer_frame_is_ephemeral_and_owner_scoped, test_http_observer_rate_limit_returns_429, and the known-gap test above.

🤖 Generated using: 🎮 rp1.run

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is d01e5f82058463709a22e93bb4cd795da5f53e10...b65166926f3d782295ee7bcef678ca912a5c1ec2.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review b65166926f3d782295ee7bcef678ca912a5c1ec2 to authorize a new review.
Any previous review applies only to its recorded range.