GET /_matrix/client/v3/directory/room/{roomAlias} is badly designed and leads clients into unsafe behaviour

https://spec.matrix.org/v1.10/client-server-api/#get_matrixclientv3directoryroomroomalias
(& also probably https://spec.matrix.org/v1.11/server-server-api/#get_matrixfederationv1querydirectory)

There are a few major issues with this endpoint relating to the `servers` property

1. The `servers` provides a list of ALL the servers that are joined to the room. This can be a huge list that clients will naively craft into matrix.to urls or use to join the room with.

2. There is no warning text about the length of the `servers` property or the implications of selecting servers from the list (such as room hijacking).

3. In the response property `servers` we have the description `A list of servers that are aware of this room alias.` This is probably not quite as strong as it should be in suggesting that it will return ALL the servers that are joined to the room.

Ideally the endpoint would be scrapped entirely and replaced with an endpoint that selects the servers via the rules described [here](https://spec.matrix.org/v1.10/appendices/#routing) rather than unloading that responsibility onto client devs that are much less likely to be aware of these rules or spend the time getting them right. If they even have the infrastructure in their client to introspect on the room state.

Start with the linked Client-Server and Server-Server API endpoint definitions, then read the routing appendix referenced in the issue. Compare the current `servers` behavior with the proposed routing responsibilities and determine whether a replacement endpoint or revised response guidance is needed. Done means the specification has an agreed, precise API design.

Written by the indexing model from the issue text.