docs: cron intervals are requested cadence, not a guarantee

[tend-agent]

Both adopter-facing descriptions of the scheduled workflows state their cron intervals as if GitHub honours them. It does not — GitHub runs schedule triggers on a best-effort basis and drops ticks under load — so an adopter reading "Every 15 minutes" over-estimates how quickly the notifications safety net comes back around. This adds one sentence to the README's workflow table preamble and to the ## Workflows section of docs/tend.example.yaml (mirrored into the install-tend reference by the sync-install-tend-references hook). No behavior change; no numbers that will age.

The hedge is placed on the general "scheduled workflows" preamble rather than on the notifications row, because the drift is not workflow-specific: the same stretch that produced the measurements below also delayed tend's own hourly review-reviewers cron by 40 minutes on this repo.

Evidence

Measured on PRQL/prql, whose tend-notifications.yaml carries the generated cron: "*/15 * * * *". review-reviewers has recorded the created_at-to-created_at gap between consecutive tend-notifications runs every hour since early July: 148 measures, 113 of them out of band (out of band = >18.0 min, i.e. 1.2× the 15 min nominal). That is 76% of all measures, across weeks, on an unmodified generated workflow.

This window's two measures continue a stretch of the widest gaps the counter has recorded:

From	To	Gap
02:53:40Z	03:39:48Z	46.13 min
03:39:48Z	04:18:13Z	38.42 min

githubstatus.com/api/v2/incidents/unresolved.json returned [] throughout, so this is ordinary scheduler behavior rather than an incident.

Gate assessment

• Evidence level: High — 148 measures, 113 out of band, sustained over weeks on a live adopter.
• Structural vs stochastic: structural. There is no tend-side decision point and no lever — the cron is already at the minimum useful granularity and GitHub drops ticks regardless.
• Change type: targeted fix (correct a specific claim), one sentence in each of two canonical files.
• Both gates pass. This also discharges a proposal that review-reviewers has carried parked for ~150 windows behind an explicit five-consecutive-out-of-band-measures trigger; the trigger reached six at the end of this window and the prior entry recorded that the next run should act rather than re-park it.

The counter tracked here is environmental, not a bot-behavior defect — the runs themselves are healthy (each new tick is an ~11 s deterministic pre-check that finds an empty inbox and skips the agent entirely). What was wrong was only the documentation's implied cadence, which is what this PR fixes. With this landed the counter is discharged and stops being carried.

Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab