fix: repair stale invoice expiry display ("3600 hours") for upgraded users

[kaloudis]

Description

Fixes a stale-settings display bug in the Receive screen: affected users saw the default invoice expiration rendered as "3600 hours" even though invoices actually expired in 1 hour.

Root cause

views/Receive.tsx stores three loosely-coupled invoice fields in saved settings:

• expirySeconds — the authoritative value passed to the backend (Receive.tsx:596-598 → backends/LND.ts:341).
• expiry + timePeriod — used only by getFormattedDuration (Receive.tsx:1214-1225) to render the duration label.

A historical regression (commit e4339e137, March 2023) initialized the default invoices.expiry to '3600' instead of '1'. The default in stores/SettingsStore.ts:1516 is now correct (expiry: '1'), but users who installed during the affected window still carry the buggy value in their saved settings, and there was no migration to repair it.

Invoices themselves were unaffected because the backend reads expirySeconds (still '3600' → 1 hour). Only the displayed label was wrong.

This is not backend-specific — it affects any user with the stale value, regardless of node implementation.

Fix

• utils/ExpiryUtils.ts — add displayFromExpirySeconds(expirySeconds), the inverse of expirySecondsFromInput. Picks the largest evenly-dividing unit (604800 → 1 Weeks, 86400 → 1 Days, 3600 → 1 Hours, 600 → 10 Minutes), falls back to Seconds for non-divisible values, and to 1 Hours for empty/invalid input.
• utils/MigrationUtils.ts — new one-shot migration MOD_KEY9 = 'invoices-expiry-display-fix' in legacySettingsMigrations. When expirySecondsFromInput(expiry, timePeriod) !== expirySeconds, recompute expiry+timePeriod from the authoritative expirySeconds. Follows the existing MOD_KEY pattern and runs once per install.
• utils/ExpiryUtils.test.ts — new test cases covering the largest-divisor preference, the Seconds fallback, and invalid input.
• utils/MigrationUtils.test.ts — new test cases asserting that the documented buggy state (expiry: '3600', timePeriod: 'Hours', expirySeconds: '3600') is repaired to (expiry: '1', timePeriod: 'Hours', expirySeconds: '3600') and that already-consistent state passes through untouched.

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• Configuration change
• Locales update
• Quality assurance
• Other

Checklist

• I’ve run yarn run tsc and made sure my code compiles correctly
• I’ve run yarn run lint and made sure my code didn’t contain any problematic patterns
• I’ve run yarn run prettier and made sure my code is formatted correctly
• I’ve run yarn run test and made sure all of the tests pass

Testing

If you modified or added a utility file, did you add new unit tests?

• No, I’m a fool
• Yes
• N/A

I have tested this PR on the following platforms (please specify OS version and phone model/VM):

• Android
• iOS

I have tested this PR with the following types of nodes (please specify node version and API version where appropriate):

On-device

• LDK Node
• Embedded LND

Remote

• LND (REST)
• LND (Lightning Node Connect)
• Core Lightning (CLNRest)
• Nostr Wallet Connect
• LndHub

Locales

• I’ve added new locale text that requires translations
• I’m aware that new translations should be made on the ZEUS Transfix page and not directly to this repo

Third Party Dependencies and Packages

• Contributors will need to run yarn after this PR is merged in
• 3rd party dependencies have been modified:
  • verify that package.json and yarn.lock have been properly updated
  • verify that dependencies are installed for both iOS and Android platforms

Other:

• Changes were made that require an update to the README
• Changes were made that require an update to onboarding

[gemini-code-assist]

Code Review

This pull request introduces a helper function displayFromExpirySeconds to convert raw expiry seconds into the largest evenly-divisible time unit, along with corresponding unit tests. It also adds a migration step in MigrationUtils to repair out-of-sync invoice expiry display settings. The review feedback points out a potential race condition in the migration block where settingsStore.setSettings is called without await, and suggests awaiting this asynchronous call to prevent concurrent write issues.