Name the room on a platform-room send: pass room_id on the claimed-room path only #881

What this is

The buildable half of #866, split out so the umbrella can stay open while its end-to-end acceptance is blocked on the platform. #866 does not close with this issue, and this issue does not close #866.

#866 stays open as the gate until Birfy/bot-social#59 lands: on b1b0b7e7 a claimed guest still gets no_relationship with the correct room_id, so acceptance 1 ("the guest's first line arrives") cannot be observed anywhere yet. This issue covers everything that can be decided, written, and pinned with the fake server in the meantime.

The two ticket paths — only one of them needs a room_id

• Local FlyBot room (#852 / #864, sendShareTo): it has no face_rooms row. Its in-room lines are room-share envelopes over plain 1:1 — room-membership.js:1092-1113 → flybotSend via: 'room-share' → social.js:1540 → send_as_member — and their authority is the seat the ticket created. A room_id here would fail roomReach gate 1 (face_rooms lookup) and come back room_not_shared. Never send one on this path. A guest's room also only exists on our side as origin: 'inbound-share' with a FlyBot remoteRoomId (war); join is not a dispatched op (room-membership.js:1287 ask, :1288 invite, :1304 leave, :1342 line), so it falls through to recordInboundSharedRoom.
• Platform room / claimed room (bot-social #43, #50): the pair may share only that room, so the line must name it. This is the only path that gets the field.

Scope

1. Step 0 — the fixture, before any code. The fake server in plugins/social/test/social.test.js:67 answers every send_as_member with a message id, and no test in that file mentions room_not_shared or no_relationship. It must learn room reach first: both Bots current members of that open room, the room's chat.public grant alive; no room_id → no_relationship; another room → room_not_shared. Until it does, a green suite proves nothing and the negative controls cannot stand up.
2. Pass room_id on the platform-room path only — the pair that shares an open face room and sends over 1:1. The call sites on main 38629bf4 are plugins/social/src/social.js:1540 (transport), :1731 and :1740 (owner-typed line); the numbers in #866's first version (:1518, :1709, :1718) are stale.
3. Map the refusals: room_not_shared and a room-scoped no_relationship each get one sentence instead of a raw platform error.

Acceptance

• The fake server refuses as described in scope 1, and undoing that far end (answering every send again) reds exactly the room-scoped cases.
• A platform-room send carries room_id; the same conversation without it is refused no_relationship (asserted on the recorded send_as_member arguments).
• A line into a local room never carries room_id — asserted on the recorded arguments, not on the room's shape.
• A send naming another room gets room_not_shared, and after Leave / room close / the grant dying the next send is refused, each as a sentence.
• No room_id on a send that is not part of a room: the 1:1 path keeps today's behaviour, friendship and approvals included.
• The PR body says in one line that the end-to-end case is blocked on Birfy/bot-social#59, and quotes the probe output that shows it.

Related

#866 — the umbrella this was split from; stays open until bot-social #59 lands.
#852 / #864 — the local-room link, which must not gain a room_id.
bot-social #43 (the platform issue), #50 (merged b1b0b7e7), #59 (the platform prerequisite).