A room-line approval card says "the room": name the room it belongs to #991

Symptom

A held line for a face-to-face room draws its approval card with the destination literally "the room": SelfTest's own reading on the bench was Waiting for approval / Chief (SelfTest B2) → the room (holdReason: face_room_auto_send_off, quoted on #977). With two rooms open that card cannot say which room the line belongs to, and the decision (Approve / Reject) sends it into a room the owner cannot identify. The room is known where the card is built — it is just thrown away.

Where (main 0553ba1e, plugins/social/src/social.js)

• approvalView() :152-195 builds the card's fields. :179 is the literal: toName: cleanText(to?.display_name) || (kind === 'face_room_message' ? 'the room' : undefined). :180 already puts roomId on the view (item.room_id || item.face_room_id || item.message?.room_id).
• The approvals listing :2960-2984 is the place that knows the live room: :2977 fills a missing roomId from holdRooms()[id].roomId, :2978 drops a card whose room is not live (faceHoldLive(item.roomId) — faceHoldLive at :2936). So every surviving card has a room id and a live room.
• The room's number is on hand as settings.faceRooms[roomId]?.joinCode (used this way at :3398 and :3656); faceRoomTitle(...) builds the human title from the same inputs.
• Two renderers print item.toName and each has the same bare fallback: plugins/social/client.js:593 and :1937 (readableParty(item.toName) || (item.kind === 'face_room_message' ? 'the room' : ...)).

Expected

A room-line card names its room — the number the owner typed (the room 482913), or the room title — so two open rooms produce two distinguishable cards. Anything the owner can match to the room he sees is enough; the bare "the room" cannot be.

Acceptance

1. Red test first: two live face rooms (two settings.faceRooms entries with different joinCodes) each holding one line → each card names its own room; neither reads a bare the room. Fails at 0553ba1e, passes after.
2. A single open room still names it (not "only when ambiguous"): the number is there in the one-room case too.
3. A legacy hold with no roomId, or a room that is no longer live, keeps today's rule: no card anywhere (:2977-2978 unchanged).
4. toName stays a plain string and approvalView keeps a fallback, so neither renderer (client.js:593, :1937) can print undefined for a card built by an older shape.
5. Docs and changelog: docs/subsystems/social.md's sentence about the card naming the recipient (Friend's Bot named four ways in one DM; approval card reads 'Chief → Chief (SelfB1233)' after reload but 'Chief → SelfB1233' before; pick one person-first format #498) also says the room is named, and changelog.d/ has a fragment (the owner sees the difference).
6. plugins/social suite green, and no change to the approve / reject path or to faceHoldLive's liveness rule.

Out of scope

• The approval flow itself: The room-line approval card has never been proven through the room input box (only through the API, which cannot make one) #977 verifies it end to end (room input box, approve → the line enters the room, reject → nothing delivered). This issue is only the name on the card; closing The room-line approval card has never been proven through the room input box (only through the API, which cannot make one) #977 is not implied by this.
• The social dock and overlay wording outside these two fallbacks.
• Any shell change.