feat: veworld connected wallet should be able to manage a sa

[Agilulfo1820]

Currently only users connected with privy can manage the smart account, this is hardcoded.

But theoretically a user could transfer the ownership of a smart account or export his PK and import in veworld.

We should always check: does this wallet have a deployed smart account? If yes then it should not matter if it is connected with veworld or privy, the smart account should be the active account.

Since now each public address has a unique smart account it's easy to find it, but when a smart account is being transferred then it is a bit more difficult to know which smart accounts a user has. This should be separated in another issue to solve the the smart accounts contracts side.

[Agilulfo1820]

Conversation Summary (in English)

Context: Dan and Victor are discussing the possibility of migrating or transferring an existing Smart Contract to a different owner or address.
Migration Procedures: Victor recalls that a similar request had been raised before, and mentions that standard documentation about “migration” usually applies to moving from one provider to another, which might not be directly applicable to their case.
Transfer Ownership: Dan points out that they have already included a clause in the smart contract that allows for transferOwnership. This can serve as a fallback if typical migration techniques are not feasible.
Multiple Smart Accounts: Dan explains that right now there is a 1:1 mapping between a wallet and a smart account, but they are considering introducing a new mapping in the smart contract to allow multiple smart accounts per wallet.
Self-Destruct: Victor mentions the possibility of using selfdestruct (or SELF_DESTROY), especially if the EVM version is old enough to include it. He observes, however, that this is a rather drastic measure.
Deploy Logic: Dan also notes that they use a function getAddress() to calculate in advance the SHA-derived address for a user’s contract. This address might never be deployed if not needed. If the system moves to support multiple smart accounts per wallet, the UI can show any or all that have been deployed, giving the user a choice.
Solution Summary
Fallback with Ownership Transfer
The existing transferOwnership function can handle a scenario where you need to change contract ownership without doing a traditional “migration.”

Support Multiple Smart Accounts
Rather than forcing a single account per wallet, allow a wallet to have multiple smart accounts through an additional mapping on the contract. This way, users can select which smart account to deploy or use.

Selfdestruct as Last Resort
While technically possible in older EVM versions, selfdestruct is considered an extreme approach and might not be ideal or even supported in all environments.

Overall, the plan is to enhance flexibility by allowing multiple accounts per wallet and to rely on the built-in transferOwnership function for changing a contract’s owner.