Improperly falling back to unstable endpoint for room hierarchies

Nobody has claimed this yet.

In [`federationclient.go / RoomHierarchy`](https://github.com/matrix-org/gomatrixserverlib/blob/1b697d109d8781f9a1aba3b6f2a49de7bcae5fa6/fclient/federationclient.go#L713), we fall back to the unstable endpoint if the spec endpoint returns 404.

However, the [spec](https://spec.matrix.org/v1.7/server-server-api/#get_matrixfederationv1hierarchyroomid) states that 404 is a valid response of this endpoint, in the case where a room is unknown or the server is otherwise unable to peek it. But the error that is ultimately returned isn't this 404, but rather another `M_UNRECOGNIZED` 404 error from the unstable endpoint.

This just obfuscates the original error, making logs harder to interpret - perhaps we should not just check for 404 on the spec endpoint but also check for `M_UNRECOGNIZED` before falling back to unstable, and if both the unstable and spec endpoints error, somehow pass on both errors with some information that we re-tried.

Or maybe, since MSC2946 has been spec for quite a while, we just remove the whole fallback to unstable mechanism in the first place?

Start in fclient/federationclient.go at RoomHierarchy and compare its 404 fallback with the linked Matrix v1.7 endpoint specification. Resolve whether the unstable fallback remains supported, then verify that an unknown or unpeekable room preserves the meaningful spec response and that the chosen retry behavior is covered by tests.

Written by the indexing model from the issue text.