Clarify that MSC3827 also affects federation endpoints

matrix-org/synapse#13031 originally added support for the feature to Synapse, which although doesn't include an obvious federation route it does end up sending the field over federation.

[Here](https://github.com/matrix-org/synapse/blob/a6895dd576f96d7fd086fb4128d48ac8a3f098c5/synapse/federation/transport/client.py#L481) the server copies the search filter just before it goes over the wire, which is supplied by through a chain of function calls originating [here](https://github.com/matrix-org/synapse/blob/c6d617641186221829c644204f24654430858826/synapse/rest/client/room.py#L456). 

Additionally, it is clear that this sort of feature would have included federation given the filtering is able to be proxied directly like this (as demonstrated by Synapse above).

As such, this is determined to be a clarification/minor edit to the MSC, not requiring a second MSC to add the functionality.

proposals/3827-space-explore.md

@@ -52,6 +52,11 @@ in the `room_types` array. If the `room_types` filter is not specified or the
 `room_types` array is empty, the server should return _all_ rooms no matter the
 type.
 
+The same API shape is added to the Server-Server API for the [public room directory](https://spec.matrix.org/v1.3/server-server-api/#public-room-directory),
+allowing servers to proxy the request over federation if needed. Note that the
+remote server might not support this filtering mechanism - the local server should
+further filter the results if needed/possible.
+
 ## Alternatives
 
 ### Using a special endpoint