Password and SRP persist in Hermes heap after autolock; fix named in `wipeSensitiveData` comment

### What is this about?

`Authentication.wipeSensitiveData` is called at ten sites to clear passwords and SRPs on lock, but its body is `() => ''`. In JavaScript that reassigns a pointer; the original bytes stay in the heap.

https://github.com/MetaMask/metamask-mobile/blob/554fffd564f110dafcedff66c35c85280370ab15/app/core/Authentication/Authentication.ts#L296-L304

The function's own comment names the fix: represent passwords and SRPs as `Buffer` / `Uint8Array` and zero them — the approach the linked extension commit ([`98f187c30117`](https://github.com/MetaMask/metamask-extension/commit/98f187c301176152a7f697e62e2ba6d78b018b68)) implements.

Verified on `io.metamask` v7.76.0 (Android 14, `adb root`, Frida): after the 30-second autolock fires and the password-entry screen is showing, the 12-word BIP39 mnemonic and the password sit at the same heap addresses, unchanged. One test held the mnemonic for ten minutes with the app backgrounded — zero bytes changed. Each unlock/lock cycle adds another plaintext copy at a new address without zeroing the prior one.

Same vulnerability class as Halborn's **Demonic** ([disclosure](https://www.halborn.com/disclosures/demonic-vulnerability), [CVE-2022-32969](https://nvd.nist.gov/vuln/detail/CVE-2022-32969)), patched in the browser extension in 2021.

The bundled `hdkey` already ships `HDKey.prototype.wipePrivateData` for the keyring leg — no caller from the lock path invokes it. The password also reaches memory via the RN bridge as plaintext JSON on every keystroke; `secureTextEntry` masks the UI but does not prevent this.

**References**

- Full disclosure with runtime evidence, threat model, and timeline: https://hexproof.dev/datagrams/metamask-demonic-mobile-android/
- Halborn Demonic disclosure: https://www.halborn.com/disclosures/demonic-vulnerability
- MetaMask's 2022 statement (*"The following does not impact MetaMask Mobile users."*): https://medium.com/metamask/security-notice-extension-disk-encryption-issue-d437d4250863
- Stub introduced in [PR #5374](https://github.com/MetaMask/metamask-mobile/pull/5374) (2023-02-24, *"Authentication refactor"*)
- Extension fix the comment names: [`98f187c30117`](https://github.com/MetaMask/metamask-extension/commit/98f187c301176152a7f697e62e2ba6d78b018b68)

Read app/core/Authentication/Authentication.ts around lines 296-304, then trace the ten callers through the lock and autolock paths. Compare the comment's Buffer/Uint8Array approach with extension commit 98f187c30117 and inspect the bundled hdkey wipePrivateData path. Done means sensitive password and SRP data is explicitly cleared across these paths rather than left in prior heap locations.

Written by the indexing model from the issue text.