buzz-acp: expose OBSERVER_PUBLISH_TICK as configuration

## Summary

Headless VPS agents with `BUZZ_ACP_RELAY_OBSERVER=true` (required for Desktop View Activity) publish observer frames at a hardcoded **1 frame/s** (`OBSERVER_PUBLISH_TICK` in `lib.rs:392`). Those frames bill the agent's **`LimitType::Messages`** quota (`agent_standard_messages_per_min` = 120), **shared with real chat messages** (`lib.rs:380-392`, `connection.rs:692`).

At 1/s, telemetry consumes up to **~60/min — half the budget** — regardless of channel count. The source comment already names the knob: *"A slower tick (e.g. 2s → 30/min) would leave more quota headroom for chat at the price of doubled viewer latency"* — but the constant is not configurable.

## Observed behavior (2026-08-25, Globis on bots VPS)

After harness restart with observer enabled, journal shows repeated `relay NOTICE: rate-limited: quota exceeded` for ~17 minutes. This matches the post-reconnect snapshot drain: up to **1,000 events** from `OBSERVER_BUFFER_CAP` (`observer.rs:18`) published at 1/s. Not a relay bug — expected when the replay buffer fills after restart.

## Proposal

Expose `OBSERVER_PUBLISH_TICK` (or `BUZZ_ACP_OBSERVER_PUBLISH_TICK_SECS`) as env/config, default **1** (current behavior).

Example tradeoffs:
| tick | telemetry max/min | chat headroom (of 120) |
|------|-------------------|------------------------|
| 1s | ~60 | ~60 |
| 2s | ~30 | ~90 |
| 5s | ~12 | ~108 |

## Scope

Small config surface change — separate from #6826 (idle/liveness signal mismatch).

## Workaround today

None without recompiling. Operators should expect ~half quota per agent with observer on, and transient rate-limit spam after restart while the replay buffer drains.