fix(android): drop setUnlockedDeviceRequired from rootkey wrapper key

[gmaclennan]

Summary

• Drops setUnlockedDeviceRequired(true) from the AndroidKeyStore-backed rootkey wrapper key generated by RootKeyStore.

Why

setUnlockedDeviceRequired(true) has two failure modes that are unacceptable for a key whose loss equals identity loss:

1. Generation requires a configured secure lock screen. Devices without a PIN/pattern/password fail to generate the wrapper key, and the FGS bricks at startup with a rootkey error. Many CoMapeo users — community/conservation contexts, often on shared or no-lock devices — would simply not be able to use the app.
2. Permanent invalidation on lock-screen toggle. Per KeyPermanentlyInvalidatedException and OWASP MASTG-KNOW-0043, keys are "permanently and irreversibly invalidated once the secure lock screen is disabled". Re-adding the lock screen does not recover the key. A user who briefly disables their PIN loses their CoMapeo identity in every project they participate in.

What we keep

The wrapper key remains:

• Hardware-backed (StrongBox if available, TEE otherwise)
• AES-256 GCM, non-extractable
• Scoped to this app's signing certificate
• Persisted as an encrypted envelope in SharedPreferences

The only attack surface gained: code execution as our app while the device sits in the post-boot, pre-first-unlock state could decrypt the rootkey envelope. There is no practical path for that on current Android even without the gate, and it's a vanishing concern relative to the identity-loss failure modes above.

Prior art

expo-secure-store — the de-facto standard secret store on Expo/RN Android — makes the same trade and omits this flag. Its default-case wrapper key uses only setUserAuthenticationRequired(false); no lock-screen-tied attributes.

Test plan

• Existing RootKeyStoreTest instrumented tests still pass on a device with a configured screen lock (no behavior change for that path).
• Fresh install on an emulator/device without a configured screen lock: FGS reaches STARTED, wrapper key generates, rootkey persists, second launch returns the same bytes.
• Fresh install on a device with a configured screen lock, then disable the lock: subsequent launches still load the existing wrapper key (no invalidation, since fresh keys generated under this PR don't have the unlock-required gate). Re-enable the lock: still loads.
• Manual sanity that the comment block accurately describes the rationale (no separate runtime check needed).