fix(desktop): register a community field clear as a real change

[shawnhank]

Summary

resolveCommunityUpdateResult (desktop/src/features/communities/useCommunities.tsx) gates whether a community edit persists on a hasChange check. For the two optional, clearable fields (token, reposDir), that check was updates.<field> !== undefined.

Clearing either field to empty always produces exactly undefined (the dialog's expandTilde("") / token.trim() || undefined both resolve an empty input to undefined, matching Partial<Community>'s existing "clear this field" convention). So a save whose only change was clearing reposDir or token was classified unchanged and silently dropped — the field looked cleared in the dialog, then reverted to the old value the next time it was opened, with no error and no indication anything went wrong.

Live repro: set a community's Repos Directory to a path, clear the field, Save Changes, reopen — the old value is back.

Fix

Check key presence (Object.hasOwn(updates, "token" | "reposDir")) instead of value for these two fields, so an explicit clear-to-undefined registers as a real change, the same as any other edit. name/relayUrl/pubkey are unaffected — they're never intentionally cleared through this path.

Test plan

• Added 3 regression tests to resolveCommunityUpdateResult.test.mjs: clearing reposDir alone registers as updated/requiresReinit: true; clearing token alone does the same; omitting the key entirely (genuinely untouched) still correctly resolves to unchanged.
• node --import ./test-loader.mjs --experimental-strip-types --test src/features/communities/resolveCommunityUpdateResult.test.mjs — 12/12 pass.
• Full desktop suite (pnpm test) — 5,102/5,102 pass, no regressions.
• tsc --noEmit clean.
• Confirmed via git show that the bug is present in both the desktop-v0.5.16 and desktop-v0.5.17 tags, not a recent regression.

🤖 Generated with Claude Code