feat(config/channels): add reply_min_interval_secs to TelegramConfig

[singlerider]

Summary

Adds the reply_min_interval_secs: u64 field on TelegramConfig, defaulting to 0 (current behaviour: replies fire as soon as the LLM completes). The intended range is 0..=3600.

The threat model: on paired-identity channels under personal accounts, sub-second replies are a strong AI-tell and a platform-side anomaly signal. Raising this value paces the agent so its cadence resembles a human operator's.

This commit ships the schema field for Telegram. Mirroring the field to other channels, load-time range validation, and the per-(channel, peer-jid) outbound scheduler that honours the interval are tracked separately and will land in follow-up PRs against the same issue.

Closes #6345

Validation Evidence

cargo fmt --all -- --check
cargo clippy --workspace --exclude zeroclaw-desktop --all-targets --features ci-all -- -D warnings
cargo check --workspace --exclude zeroclaw-desktop

All three pass locally. Every existing TelegramConfig struct literal has the new field added (default 0); CI catches any new construction site that omits it.

Security & Privacy Impact

• New permissions, capabilities, or filesystem access scope? No. The eventual scheduler is the actual safety lever; this commit only adds the schema surface.
• New external network calls? No.
• Secrets / tokens / credentials handling changed? No.
• PII or real identities in diff, tests, fixtures, or docs? No.

Compatibility

• Backward compatible? Yes. Default 0 preserves current behaviour byte-for-byte. Existing configs deserialize cleanly without the key set.
• Config / env / CLI surface changed? Yes (additive). New reply_min_interval_secs key under [channels.telegram]. Same name will be added to other channels in follow-ups.

Rollback

git revert <merge-sha>. Schema-only diff; no runtime is wired to the field yet, so a revert is byte-equivalent to current behaviour.

[Audacity88]

Reviewed head a163123. I checked the fetched PR state, linked issue #6345, the existing #6345 triage comment, the full diff, the config-schema source around TelegramConfig, CI status at fetch time, and the relevant ZeroClaw review/docs/governance guidance. There are no prior PR comments, inline comments, or formal reviews. I did not run local cargo; CI is green. Local checks were git merge-tree --write-tree origin/master origin/pr/6389 and git diff --check origin/master...origin/pr/6389.

🟢 What looks good — the schema slice is narrow and default-safe

The actual code change is small and low-behavior-risk: reply_min_interval_secs is added to TelegramConfig with #[serde(default)], and every existing TelegramConfig struct literal is updated with 0. That preserves existing behavior for users who do not set the new key. The follow-up commits also cleaned up the stale present-tense docstring claims and removed the unrelated generated docs reorder, which keeps this PR focused.

🔴 Blocking — Closes #6345 would close work this PR explicitly defers

The PR body says this is only the Telegram schema-field slice. It explicitly defers mirroring the field to other outbound channels, load-time range validation, and the per-channel/per-peer outbound scheduler. The linked issue #6345 is broader than this PR: its acceptance criteria require the field across supported channels, 0..=3600 validation, delayed outbound delivery, bounded queue behavior, and docs.

If this merges with Closes #6345, GitHub will close the tracker even though the actual pacing behavior has not landed and the remaining acceptance criteria are still open. That would make the work look complete when the PR itself says it is only the first step.

Please either change this PR to Refs #6345 and keep #6345 open, or open/link concrete follow-up issues for the remaining scheduler, validation, cross-channel, queue, and docs work before closing the tracker. If the intent is for this PR to fully close #6345, then the remaining acceptance criteria need to land here.

🟡 Warning — validation evidence should include command output

The PR says fmt, clippy, and check all pass locally, but the validation section summarizes the results without command output. CI is green, so I am not treating this as a code blocker, but the section should paste the command output tails or explain why local output is intentionally omitted.