docs(WalletBase): note SignMessage(null) overload ambiguity

CodeRabbit flagged that adding SignMessage(string) creates a CS0121
overload-resolution ambiguity for callers passing a literal null, since
null is implicitly convertible to both byte[] and string. The runtime
null guard already throws ArgumentNullException for the string overload,
and the byte[] overload predates this PR, so renaming would break the
expected C# overload pattern. Documented the limitation per CodeRabbit's
first suggestion so external consumers know to cast (byte[])null or
(string)null when they need to.

Author: mstevens843

Runtime/codebase/WalletBase.cs

@@ -270,6 +270,13 @@ public virtual async Task<RequestResult<string>> SignAndSendTransaction
         /// </summary>
         /// <param name="message">The string message to sign</param>
         /// <returns>The signature bytes</returns>
+        /// <remarks>
+        /// This overload coexists with <see cref="SignMessage(byte[])"/>. Passing a
+        /// literal <c>null</c> (e.g. <c>SignMessage(null)</c>) is ambiguous between
+        /// the two overloads at compile time (CS0121); cast to <c>(byte[])null</c>
+        /// or <c>(string)null</c> to disambiguate. Typed variables and non-null
+        /// string/byte[] expressions are unaffected.
+        /// </remarks>
         public Task<byte[]> SignMessage(string message)
         {
             if (message == null) throw new ArgumentNullException(nameof(message));