A Feishu task's template names the commands but not the identities they run as, and files its questions where the host does not read #2479

What happens

emrg/server/feishu_prompt.md is the instruction set a scheduled feishu task runs under: a
round reads the host's Feishu conversations, judges each message and answers it. Four rules the
round depends on are not in the file, and each has a measured consequence on a live
installation.

1. §3 names the send command without the identity that has to carry it. The section reads
lark-cli im +messages-send --user-id <open_id> (or --chat-id <id>) carries the text. The CLI
resolves an unstated identity through its own auto default, which prefers the user account
once that account is authorised — and the message then lands in a conversation whose name is the
host's own, i.e. the host messaging himself, which Feishu raises no notification for. Measured
2026-10-22: a send without the flag arrived in that self-conversation silently, while the same
text sent with --as bot --user-id ou_… arrived in the bot↔host conversation and the host was
notified immediately. Both calls exit successfully, so the round cannot tell them apart.

2. §1 says how to read a conversation but not which identity reads, nor which listing answers
"has the host replied". Reading a direct conversation needs the user identity, so the identity
that reads is not the identity that sends. im +messages-search answers out of an index that
lags a send by seconds, so it cannot establish that nothing came back;
im +chat-messages-list --chat-id <id> is the listing that can. §3's own rule — read the
position, not the clock — is executable only if the round also knows that the conversation to
read is the one its own last message landed in.

3. §3 covers a draft awaiting approval, not an open question. One clause says the host's
channel is also the channel for asking, and every procedure under it describes the case where
the recipient and the exact text are already known. A question with no text to quote — does this
need an answer at all, what should it say, would the host rather do it himself — has no
procedure, so the round carries it into the report, where the host does not read it.

4. §4 makes the report the place a question goes. The report is asked to state "which
requests are waiting for the host — with their full text and recipient". A round that reports a
pending request has therefore satisfied §4 in full while the host has been told nothing.

What the fix must satisfy

• §3 states the send command with its identity and its recipient, and says what happens when the
  identity flag is left out, so a round that omits it can recognise the outcome.
• §1 states the identity that reads, the listing that answers whether the host replied (with why
  the search index cannot), and that the conversation to read is the one the round's own message
  landed in.
• §3 gives a procedure for a question addressed to the host that has no text yet: send it on
  that channel this round, do not wait for the answer, read it next round. The word-for-word
  requirement stays attached to messages a third party will receive.
• §4 says the report is a record rather than a channel: a request it reports as waiting names
  the Feishu message and the conversation it was asked in, and one without them counts as
  unasked rather than as progress.
• A test pins each of these to the section that owns it, and removing the rule a pin names turns
  that test red.