Face room: friend's plain line bypasses face-room routing and no-follow-up rule #462

Problem

In a Face-to-face room, a friend's (peer's) attested plain line skips face-room routing (#299) and the one-pass "no follow-ups" rule (#295). The cause is how the line is tagged on the way in. It reaches the round as a regular group post from a sender id, not as a person's face-room line.

Effects:

• The wrong Bots may answer a friend's line. It uses the plain speaker list (admin first, then everyone up to FACE_PLAIN_SPEAKERS), not the routed "Bots decide who answers / last speaker first" path.
• The round is not single, so a Bot that @-mentions another Bot in its answer can call it on. The no-follow-up rule does not apply, and Bots in two homes can set each other off.

Related: #456 / PR #461. #461 only adds an answer-at-most-once-per-line limit (faceLine) on top of this. It does not fix the routing. The owner decided to track this as a separate bug.

Where (main b2c2e1c)

• Tag assigned: core/src/host/hooks.js → flybot.rooms.postHuman() (around L1016–1033). It is called from plugins/social/src/social.js (around L2718). It works out plain / everyone / callIds and then calls rt.postToRoom(room, { id: 'face-notice', name: who }, text, { quiet: true, notice: true, human, plain, ... }).
• core/src/host/groups.js → postToRoom() (around L702). It wraps every call as source: { kind: SOURCE_KIND, role: 'post', senderSessionId: sender.id, ... }. So the friend's line becomes an ordinary "[Group post from X]".
• core/src/host/turns.js (around L352–370). A role: 'post' source is queued with botId: source.senderSessionId. So the friend's line arrives with botId: 'face-notice', plus notice/quiet/plain.
• Routing decided: core/src/host/groups.js
  • isPlainFaceLine() (around L655) returns false straight away because opener.botId !== undefined. The if (opener.plain) return true branch is never reached for a friend's line.
  • So routeFor() (around L313) returns undefined: there is no route, and its fallback: opener.plain !== true branch, meant for friend lines, is dead code. Also, round.single (around L519) is never set, so callMembers (around L456) still runs Bot-triggered follow-ups.
  • openingSpeakers() (around L662) hits the opener.plain && isFaceRoom(room) branch and returns plainSpeakers(members, admin). That is unrouted.
  • Also in the relay round (around L479): event() treats notice / botId === 'face-notice' as an event. The opener is then picked by the ?? posts.at(-1) fallback, and that only works by accident.

Expected (needs owner confirmation before agent-ready)

A friend's attested plain line is routed exactly like a face-room person line: under the room's #299 routing (Bots decide who answers, last speaker first, fallback false so the friend's own home covers an all-pass) and the #295 single-pass no-follow-up rule. This likely means tagging it as a person's face line (no Bot botId) instead of a face-notice group post, or making isPlainFaceLine handle human/plain openers.

Note: the fix changes which Bots answer a friend's line. The owner must confirm the expected behavior above before this is marked agent-ready.

Tests to add

In core/test/rounds.test.js: a friend's attested plain line in a face room gets a route and single: true, and a Bot's @mention in its answer does not call another Bot on. A friend's @bot line (callIds) is unchanged.