Using `wantReply` on an `ChannelSignalMessage` can lead to deadlock

In both the C# and TS implementations, the ChannelSignalMessage explicitly sets wantReply to false before sending:

https://github.com/microsoft/dev-tunnels-ssh/blob/1cd94f90ee5b9cc55120d050a499af094dbd0b8e/src/ts/ssh/messages/connectionMessages.ts#L403

However, this change is done while the message is being written to binary, after the SshChannel checks the value:

https://github.com/microsoft/dev-tunnels-ssh/blob/1cd94f90ee5b9cc55120d050a499af094dbd0b8e/src/ts/ssh/sshChannel.ts#L201

This means that if you set wantReply on the message, the SshChannel will wait for a response which will never come, because it wasn't actually asked for.

This is easy to reproduce:

const signalMessage = new ChannelSignalMessage();
signalMessage.signal = 'INT';
signalMessage.wantReply = true;

// get a channel...

const res = await channel.request(signalMessage); // Deadlock!

There's no comment on the line that overrides the wantReply value so I'm not sure the purpose of it - reading the OpenSSH source it seems like wantReply is valid for a signal message and would be handled.

If this is intentional, it would probably just be best to remove the wantReply property from the ChannelSignalMessage. Otherwise, it would be good to remove the override.

Start with src/ts/ssh/messages/connectionMessages.ts around ChannelSignalMessage and src/ts/ssh/sshChannel.ts around the request check, then locate the corresponding C# implementation. Reproduce the wantReply=true example and verify that the chosen behavior no longer leaves channel.request waiting for a response that was not requested.