feat(resolver): resolve names on contracts that serve the ENS resolver profile without a registry

[petfold]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it. (The resolver-options flag help is updated here; the docs site's page on ENS would want one sentence, which I can submit to the docs repo once this lands.)
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

Lets resolver-options point at a contract that serves the ENS resolver profile itself (contenthash, addr, text on EIP-137 name hashes) without an ENS registry in front, as the Gwei Name Service (.gwei) does. Today the ENS client requires a registry: wrapDial calls owner("") to check the contract and wrapResolve calls owner/resolver before contenthash, so such contracts fail on dial.

Change, confined to pkg/resolver/client/ens:

• wrapDial: if the registry probe fails, call EIP-165 supportsInterface(0xbc1c58d1) (the contenthash profile, ENSIP-7) on the same address. If it answers true, keep the connection and return a nil registry; otherwise fail as before.
• Client: a nil registry with a live client marks the contract as a direct resolver; Resolve then uses wrapResolveDirect, which reads contenthash through goens.NewResolverAt(ethCl, name, contractAddr). An empty record maps to resolver.ErrNotFound ("name is not registered"), other errors keep today's classification.
• Registry behaviour is unchanged; existing tests pass unmodified. New tests: TestResolveDirect (direct path chosen when dial returns no registry, registry path not used, contract address and name passed through, not-found and not-implemented cases) and TestSupportsContenthash (EIP-165 call encoding and decoding against a fake caller).
• --resolver-options help text mentions the second kind of contract.

Live check against mainnet with this branch, WithContractAddress("0x9D51D507BC7264d4fE8Ad1cf7Fe191933A0a81d6") on a public RPC:

swarmtyp.gwei                       -> b656fac57eb02756af40279cf70275969c9f9219818af7cceee34101f169a100
app.swarmtyp.gwei                   -> b656fac57eb02756af40279cf70275969c9f9219818af7cceee34101f169a100
definitely-not-registered-xyz.gwei  -> name is not registered: not found: resolve failed
(1.2 s for connect + three lookups)

Configuration that then works end to end:

resolver-options:
  - "gwei:0x9D51D507BC7264d4fE8Ad1cf7Fe191933A0a81d6@https://<mainnet rpc>"

GET /bzz/swarmtyp.gwei/ serves the Swarm feed manifest the name points at.

go build ./..., go vet and go test -race ./pkg/resolver/... pass locally; I could not run make lint here (no golangci-lint), happy to fix anything it reports.

Motivation and Context (Optional)

GNS names (.gwei) are resolved by Freedom Browser natively and served by the <name>.gwei.domains gateway, so Swarm sites under .gwei names exist today; Bee and Swarm Desktop users are the ones who cannot open them by name. GNS's NameNFT implements contenthash(bytes32 node), addr, text and supportsInterface for the standard profile ids, with token id = uint256(namehash) (contracts: https://github.com/lucadonnoh/gwei-names). The same mechanism covers any other registry-less service that adopts the resolver profile.

Per CONTRIBUTING this is opened as a draft pending consensus on the issue; the diff is small and self-contained, so I hope it helps the discussion.

Related Issue (Optional)

Closes #5600

AI Disclosure

• This PR contains code that has been generated by an LLM.
• I have reviewed the AI generated code thoroughly.
• I possess the technical expertise to responsibly review the code generated in this PR.