Investigate adding eth<>oasis addr mappings from incoming api requests

[pro-wh]

Imported from https://app.clickup.com/t/869683dzx

Nexus currently derives its knowledge of eth<>oasis addr mappings from the evm txs it sees from on-chain. However, in some use cases a user may deposit rose into an evm (sapphire) account, and when viewing this account on the sapphire explorer Nexus will not have the corresponding eth addr info. (since consensusaccounts.deposit is not an evm tx). However, if the nexus api server sees an incoming request for an evm-style address, we could potentially have the api server update the db to include the new address. (We can derive the eth ➝ oasis addr easily, but not vice versa)

Caveats:

1. the Nexus api is designed on purpose to be read-only, which allows us to scale it up easily to accomodate traffic. It also prevents malicious requests from corrupting the db.
2. We have no authentication/rate limiting on the api side currently; we need to be careful about allowing these updates
3. Luka pointed out that this is only an issue for accounts that have never interacted with Sapphire aside from consensus deposit. Once the user interacts with the evm, the mapping will be tracked by Nexus