#41790 fix(a11y): Incorrect `li` markup being used in message lists

Proposed changes (including videos or screenshots)

Both message lists were rendering <li> elements inside virtua's VList. That container is a <div> with role="list", and VList wraps every row in another <div> — so those <li> had no <ul>/<ol> parent. Invalid markup, and an li outside a list maps to generic rather than listitem, so those rows were not exposed as part of the message list.

Replaced them with div elements carrying the right role:

• load-more placeholders → role="presentation" (they're not list items)
• room foreword → role="listitem"

This matches what the rest of the list already does — RoomMessage and the message divider both use role="listitem" on a div. .load-more is a class selector, so the styles are unaffected.

Introduced in #40105, which swapped the <ul> containers for VList but carried the <li> children over unchanged.

Issue(s)

Steps to test or reproduce

1. Open a channel with enough history to show the room foreword and the load-more placeholders.
2. Inspect div[role="list"].messages-list — no <li> should remain.
3. Same for the thread contextual bar.
4. Run axe on the room view: the listitem violation ("<li> elements must be contained in a <ul> or <ol>", serious) is gone.

Further comments

CORE-2655

Summary by CodeRabbit

• Accessibility
  • Improved semantic structure and ARIA roles for message and thread list loading states.
  • Updated room foreword markup to preserve list-item semantics within virtualized lists.
  • Improved accessible naming and message list-item recognition for room and thread conversations.
  • Added accessibility validation across loading, pagination, and message display states.