The receiving side names a shared room after the Bot that transmitted the share, not the person who invited #873

The receiving half of #848. The sender now puts the right person in the envelope; the receiving host still names the room after whoever transmitted it.

What happens today

core/src/host/room-membership.js:1212-1217 at 699b650d:

const fromHandle = event.fromHandle || data.inviterHandle
const fromHome = event.fromHome || data.inviterHome
const fromName = cleanPeerName(event.fromName || data.inviterName, 'a friend')

event.* is the transport sender — the Bot Social display name of the Bot that delivered the line. data.* is the envelope, and it is the only place the inviter is named. The transport wins every field, so fromName becomes the sender's Bot name and sharedFrom.inviterName is recorded with it (:1230, :1250), which is what sharedRoomTitle renders at :262.

Seen in a real run (SelfTest, fdecbfa0, evidence on #848 comment 6364819259): the delivered payload carried "inviterName":"SelfTest A2","inviterHome":"@selftesta2.home", and the receiving side still recorded "inviterName":"Chief" — the name of the Bot that sent it. The room title reads Shared room from Chief instead of the person who invited.

core/test/remote-room.test.js:854 currently pins that: with inviterName: 'Alice' in the envelope and fromName: 'Chief' on the event, it asserts room.sharedFrom.inviterName === 'Chief'. That assertion encoded the bug and is expected to change to 'Alice' — it is not a test to delete.

What we ask

In applyInboundRoomShare, prefer the envelope for the identity it owns, and keep the transport as the fallback:

• fromName: data.inviterName first, event.fromName only when the envelope carries no name. Keep the 'a friend' floor for a name that survives neither.
• fromHome / fromHandle: same order. They are not display-only — they feed inboundOf(data.roomId, fromHome, fromHandle) at :1220, which decides whether this is the room we already have. Preferring the envelope must not fork a second room for a share recorded under the transport's home before this fix; matching has to accept the value already stored on the room as well as the envelope's.

Scope

• core/src/host/room-membership.js (applyInboundRoomShare, and only the lookup/identity plumbing it needs).
• core/test/remote-room.test.js — the assertion at :854 plus the new cases below.
• No migration: a room already recorded keeps whatever name it stored. The true inviter cannot be recovered from an old row, and guessing it from the room's members would be a second bug.

What must not change

• :1260 attributes a chat line with cleanPeerName(data.who || fromName, fromName). A line that carries who keeps who; this issue must not re-attribute room lines to the inviter.
• :1184 (the leave line) and the forward path (:985) — a forwarded share must still not be rewritten to the forwarding owner's identity.

Acceptance

1. With inviterName/inviterHome in the envelope and a different fromName on the event, the recorded sharedFrom.inviterName/inviterHome are the envelope's, and presentRoom renders Shared room from <that name>.
2. Putting the order back to event.fromName || data.inviterName reds only that case; the line, leave, forward and hop tests stay green.
3. A line that carries who is still attributed to who with an envelope name present — an explicit case, so the name fix cannot swallow line authorship.
4. A room stored under the transport's home, then a later envelope for the same roomId naming a different inviter home, resolves to the same room (no duplicate inbound-share room), and the stored room picks up the envelope's name.
5. An event with no name anywhere still records a friend — the floor does not disappear.