fix: getname behaviour

[TateB]

if a resolved primary name is not normalised, the result should be null or an error, rather than normalising the output. this was theoretically being tested already but createSubname and setAddressRecord both use the namehash function in ensjs itself, which normalises all labels, and we weren't testing for the error output in strict mode, just that the result is null.

changes:

• added normalisation check in getName. if false (not normalised), there is a new NameNotNormalisedError that can be thrown in strict mode, or non strict will return null.
• getName test now uses writeContract + viem's namehash to avoid the normalisation in the namehash from ensjs
• waitForTransaction now checks that a transaction was successful in it's receipt

[sonarqubecloud]

Please retry analysis of this Pull-Request directly on SonarQube Cloud

[v1rtl]

Test fail with an unrelated error, but otherwise seems fine. The main branch isn't the one that will be used in the future but I suppose we can backport it to the refactor branch