fix(server): resolve the dotNS controller whether the gateway stores a dispatcher or the controller

[re-gius]

Description

This is a transitional step, deliberately shaped to avoid breaking changes after paritytech/dotns#258 .

DotnsGateway.DispatcherAddress is about to change meaning. Today it holds a RootGatewayDispatcher, and discover_pop_controller calls TARGET() on it to reach the DotnsPopController. paritytech/dotns#258 moves the substrate Root check into the controller itself, after which the dispatcher has no purpose and the gateway pallet gets repointed at the controller proxy via set_dispatcher_address. From that moment the stored address has no TARGET(), discovery errors, and host username resolution stops working.

Switching outright to "the stored address is the controller" would have to land in the same instant as that extrinsic, on every chain at once. Instead discovery now works out which contract it is looking at, so one binary serves both states.

TARGET() exists only on the dispatcher and protocolRegistry() only on the controller, so a revert from one identifies the other. A revert is an answer about the contract; a node failure is not an answer at all.

TARGET()	then protocolRegistry()	Discovery concludes
returns an address	not needed	it is a dispatcher — use the address it returned (every chain today)
reverts	returns an address	it is the controller — use the stored address (after the repoint)
reverts	reverts	it is neither — error naming the address
the node fails to answer	or fails here	no conclusion — return the transport error, never an address

Not a breaking change. On every chain as it stands the stored address is still a dispatcher, TARGET() still answers, and the resolved controller is identical so the new branch is never reached. No configuration changes are needed, and HOST_CLI_DOTNS_POP_CONTROLLER still overrides discovery unchanged. Nothing here waits on dotns#258 either.

Temporary by design. Once every chain stores the controller, the TARGET() hop and the protocolRegistry() confirmation both become dead weight and discovery collapses to reading the address and using it. That cleanup is a follow-up, not part of this PR, because until then the dispatcher path is the live one on previewnet and paseo-next-v2. The cost of carrying both in the meantime is one extra reverting view per resolution after a repoint,.

The identity.rs test mock still scripts the dispatcher shape (:341, :440), matching today's chains; the new unit tests cover the repointed shape. Point it at a controller later and it panics unscripted view rather than returning a wrong address.

[re-gius]

@TarikGul it's ready for review now. The dotns release with the change that needs this will happen by the end of the week, then we will deploy on Previewnet and Paseo. After the new contracts land there, we can prepare for mainnet launch and remove the gateway check altogether, because every deployment will only have a controller at that point. So this is just a temporary tweak.