emrg: the Feishu template never tells its task that the cadence is not its to lower #2594

What is observed

A scheduled task's own cadence is decided by its record — interval, and the schedule windows that override it — and by nothing else. That is the scheduler's design: effective_interval is the single producer of "how often, right now", and the record is its only input.

The vibe check cuts across it. Every round an evolution cycle may answer recommend_slowdown: true, and the scheduler then waits at the heartbeat interval instead of the record's own — up to eight times longer. So a task's real frequency is decided by the agent's own judgement on the round, whatever the record says.

For most tasks that is a reasonable safeguard. For one whose entire value is timeliness it inverts the task: a round that found nothing is exactly the round a message-handling task should have, and it is also the round that invites the recommendation. The quieter the inbox, the stronger the case for slowing the thing that watches the inbox.

One installation already compensates: a task's supplement in tasks.yml forbids the recommendation outright — recommend_slowdown must always be false, slowdown_reason empty, and the cadence left to the record. A supplement is where a host puts configuration, not where a rule that any installation would want belongs. An installation that has not written that block has nothing stopping the slide, and nothing in the template tells the agent the cadence is not its to lower.

What is wanted

emrg/server/feishu_prompt.md carries the rule itself, as a standing rule in its own section — not folded into §1 "Read" or §2 "Judge", because it governs the round rather than any one step of it:

• the vibe check's recommend_slowdown is false on every round, and slowdown_reason stays empty;
• how often this task runs is decided by its record and by nothing else — not by how much arrived since last round, not by token cost, not by how long the quiet has lasted;
• a round that found nothing says so in one line and does no other work; that is a correct round, not a signal to slow down.

Why the template and not the supplement

The rule is about this task's purpose, which the template defines. The precedent is already in the tree: competition_prompt.md carries a §0.0 that forbids the same recommendation for the same kind of reason — a task whose value is that it keeps looking cannot be the one that decides it looks less often. One rule in two templates is the correct count; the same rule in an installation's tasks.yml is the same rule in a third place that no other installation can read.

Acceptance

What this must not do

• It must not change the scheduler, the vibe check or recommend_slowdown's meaning: this is a statement of what this task should answer, not a new mechanism.
• It must not weaken the safeguard for tasks that are not time-sensitive — the competition template's rule is the only other one, and it is the host's.
• It must not be written into any installation's tasks.yml. That file is the host's, and the point of the change is that the rule no longer needs to live there.