Validator join script silently ignores broadcaster mnemonic flag if broadcaster already exists

[WhisperNode]

Describe the bug
When upgrading chains if the script is run once you're never able to override the broadcaster address

To Reproduce
Steps to reproduce the behavior:
Example

1. Execute ./scripts/validator-tools-host.sh once with no mnemonic flag and generate a new broadcaster address "by accident"
2. kill -9 $(pgrep tofnd) && kill -9 $(pgrep -f "axelard vald-start") to stop the services
3. Execute ./scripts/validator-tools-host.sh, but this time attempting to use the broadcaster mnemonic in a .txt file and the -p flag

Expected behavior
The broadcaster address SHOULD be started up with the address generate by the mnemonic text file.

Screenshots/Log excerpts
The printed message will NOT read out with the broadcaster address generated from the mnemonic. It will match whatever address was generated in the first execution of the script no matter what.

Additional context
This has happened on every testnet chain change for us. The mnemonic flags have not worked as intended.

[ggutoski]

Thank you! We need to be careful here. Broadcaster address can never be changed after a validator has done register-proxy. Thus, we don't want to make it too easy for people to wipe out their broadcaster by importing a different mnemonic.

Because this issue arises only after user does something "by accident" I think the correct solution is to document a manual process whereby one edits on-disk data in such a way that validator-tools-host.sh will import the broadcaster mnemonic like it's supposed to.

At a bare minimum, the script should throw a warning when attempting to overwrite an existing broadcaster mnemonic.

[WhisperNode]

Another thing to think about here as well was that this occurred because of a one character typo. Perhaps if the script doesn't find the file for the mnemonic it could throw an error instead of proceeding and creating a new broadcaster account?