refactor: delete legacy migration code from AppState (Stage 2)

[DocNR]

Summary

Stage 2 of the AppState god-object split. Deletes the build-31 → multi-account migration code that's no longer needed.

The data: App Store Connect shows 4/40 users on legacy versions, none active. The worst case for those inactive users is OnboardingView + nsec re-import on next launch — equivalent to a normal reinstall. Given the build 31 → 64 gap (33+ builds, weeks/months), their proxy-side state has likely already decayed beyond what migration could preserve.

The original BACKLOG entry ("move as-is, do NOT delete") was based on the assumption that legacy users were active. The data refutes that. Cleaner to delete than to extract dead code into a separate file with a TODO-delete comment.

Numbers

File	Before	After	Δ
Clave/AppState.swift	2,261 LOC	1,934 LOC	−327
ClaveTests/AppStateMultiAccountTests.swift	487 LOC	291 LOC	−196
Total			−540 / +16

AppState.swift is −14.5% in this PR alone.

What was deleted

From Clave/AppState.swift:

• bootstrapFromLegacyKeychainIfNeeded (one-shot build-31 → multi-account)
• legacyCachedProfile (helper for bootstrap)
• migrateLegacyUserDefaultsKeys (UserDefaults shape change)
• migrateLegacyProfileImageFile (disk filename change)
• migrateRemainingLegacyKeysIfNeeded (cross-version upgrade catch-up)
• cleanupEmptySignerRowsIfSafe (build-32 regression backfill, also dead — build 32 was 30+ builds ago)
• backfillSignerPubkeyHex (helper for the above)
• 3 call sites in loadState() + their step comments
• // MARK: - Multi-account loading + bootstrap (Task 5) header
• Stale doc-comment reference in cachedImageURL to a deleted method

From ClaveTests/AppStateMultiAccountTests.swift:

• 8 tests that exclusively exercised the migration paths (set up legacy state → call loadState() → assert migrated)
• 3 stale MARK section headers
• Class doc comment updated to reflect the new surface

What was kept

• recoverAccountsFromKeychainIfNeeded — NOT legacy migration code. Handles the Apple-documented "iOS Storage settings UserDefaults wipe" scenario where Keychain persists but UserDefaults is empty (e.g., user clears "App Data" via iOS Settings → Storage).
• cleanupOrphanLegacyKeychainEntry — sunset candidate. Kept for one more cycle as a defensive sweep for any pre-existing build-31-era bootstrap orphan that was never cleaned. Doc-comment updated to flag this. Safe to delete in a few build cycles.
• The 3 corresponding tests for the kept methods.

Test plan

• xcodebuild test -scheme Clave -destination 'platform=iOS Simulator,name=iPhone 17,OS=26.4' -skip-testing:ClaveUITests on main (pre-baseline): 240 passed / 0 failed ✅
• Same command on this branch: 232 passed / 0 failed (240 − 8 deleted tests) ✅
• ** TEST SUCCEEDED ** in both runs
• Zero remaining references to deleted method names in any .swift file (grep -rnE "bootstrapFromLegacy|migrateLegacy*|backfillSignerPubkeyHex|legacyCachedProfile|cleanupEmptySigner" --include="*.swift" → empty)
• After merge: separate chore/pbxproj-build-65 PR bumps CURRENT_PROJECT_VERSION 64 → 65; archive + on-device verify (fresh install + multi-account flow exercises live loadState() path)

Worst-case impact for the 4 inactive legacy users

If any of them auto-updates and opens the app:

• They see OnboardingView
• They re-import their nsec (paper backup, password manager, iCloud Keychain — wherever they stored it)
• They re-pair their NIP-46 clients
• Profile cache, activity log, prior pairings = gone

This is the same UX as any normal reinstall scenario. Given the build 31 → 64 gap, their server-side proxy state was likely going to need re-pairing anyway.

Stages 3-4

ProfileFetcher, NostrConnectCoordinator, ProxyClient, AccountManager, PendingApprovalCoordinator extractions remain in BACKLOG. Each gets its own brainstorm + plan + PR cycle.

🤖 Generated with Claude Code