ERA Wallet + dice generated seed: is there any way to verify protection against Dark Skippy?

I’m seriously considering an ERA Wallet for long-term BTC storage. My intended setup is to generate the BIP39 entropy completely outside the device using physical dice, verify the resulting seed independently, and then import the seed into the ERA. I’d use it purely as an air-gapped signer with Sparrow, communicating only via QR/PSBT. So ERA would not be involved in seed generation at all.

There are several things I really like about ERA for this use case: it’s completely QR-only with no USB or Bluetooth, supports up to 10 separate wallets/seeds on one device, has a Bitcoin-only firmware, and the form factor/transaction display make it very appealing as a dedicated signer. The fact that I can generate the seed myself externally is also a big plus for me. My main reservation at this point is actually the company itself and the fact that ERA is a relatively new wallet from a company based in Dubai/UAE. I’m trying to compensate for that lack of track record by understanding exactly what can be independently verified from the firmware and audits.

The one thing that makes me hesitate technically is Dark Skippy / nonce exfiltration. Even with a perfectly generated external seed, a malicious or compromised signing firmware could potentially leak information about the private key through ECDSA signatures by manipulating the nonce. Since ERA doesn’t appear to advertise an Anti-Klepto/anti-exfil protocol like BitBox02 or Jade, I’m trying to understand whether there is actually a meaningful way to rule this out. Has anyone gone through the ERA firmware closely enough to determine exactly how ECDSA/Schnorr nonces are generated? Is it RFC6979, a CSPRNG, or some combination involving external randomness/commit-reveal? Is there any nonce commitment or other mechanism that would make a Dark Skippy-style attack impossible?

I’ve looked at the Keylabs audit, but I don't see a specific analysis of nonce exfiltration. What I’m really trying to figure out is whether this can be independently verified from the published firmware/source, or whether that part of the signing implementation is still closed. If someone familiar with the ERA codebase, secp256k1, or the Keylabs audit can point me to the relevant code or explain the signing flow, that would be extremely useful.