Mitigate Vanity Account Name Misdirection

**User Story**
Bitshares allows for "vanity account names" so users can create fun novel account names like "my-bts" rather than encoded hash-derived identifiers as used in address formats on most other blockchains. Although this is a valuable feature for business and personal operations it creates a _social engineering_ exploit vector for scammers. I propose we enact filtration of the common address formats used by con artists; namely: **Foreign Chain Addresses**.

As a long-term BitShares community member and frequent scam support volunteer who has explained "Account Name Misdirection" to scores of victims on a near weekly basis for years I have seen a common pattern emerge. I would like the BitShares protocol to automatically reject account name registrations that match foreign blockchain address formats (Ethereum, Bitcoin, Cosmos, etc.) so that new users cannot be tricked into sending funds to scammer accounts that mimic legitimate foreign-chain addresses. While this will not fix all fraud perpetrated on Bitshares it will close a gaping hole to the most common variant.

**Impacts**
- [x] Protocol (validation logic for account creation operations)
- [x] Security (prevention of social engineering attacks via account name spoofing)
- [x] UX (onboarding safety for new users unfamiliar with BitShares' named accounts)
- [x] Brand (reputation damage from recurring, high-profile scam losses)
- [x] Legal (liability exposure for gateways and exchanges receiving stolen funds due to address mimicry)

**Additional Context**
This is a critical issue affecting our ecosystem weekly. Scammers systematically create BitShares accounts with names matching foreign chain deposit addresses (e.g., `thor1ypgjtk59...`, `0x73f8ae5c...`, etc.). Victims, often recruited through fake trading groups by con artists, mistakenly believe they're sending BTS to their foreign-chain addresses (through a fictitious gateway protocol for a small profit) when they're actually just sending to scammer-controlled BitShares accounts that look like their address.

The losses range from hundreds to tens of thousands of dollars per incident, creating poor publicity and brand damage. Gateway operators and centralized exchanges face particular hardship - they frequently receive stolen funds when victims attempt to withdraw, creating legal liability, ethical quagmires, moral obligations, and operational headaches. These externalities thereby create disincentive for AML compliant centralized exchanges to list BTS as well as a disincentive for new regulated gateway operators to join Bitshares due to risks associated with becoming complicit in money laundering.

Current approaches (blacklisting scam accounts after thefts occur) are reactive and ineffective as the funds are already laundered off chain and the would never have been used again anyway as its associated with the particular victim. This protocol-level validation would prevent **new scam accounts** from being created in the first place, proactively addressing the root cause rather than treating symptoms, or providing condolences and explanations to victims who are are often new users of Bitshares. Implementing the approach offered here will effectively close the door if not severely disrupt the most common social engineering exploit in the Bitshares ecosystem.

Start by locating the protocol validation logic for account creation operations and review how account names are currently accepted. Define which foreign blockchain address formats are in scope and how false positives should be handled before deciding on implementation details. Done means the agreed formats are rejected during new account registration without blocking valid BitShares names.

Written by the indexing model from the issue text.