Robust contacts - backup first before saving and fallback to backup file

[weebl2000]

Problem: Contacts sometimes partially disappear on Heltec v4 and Heltec Wireless Tracker v1.2. This is likely caused by power loss or reset during a direct overwrite of the contacts file.

Solution: Atomic-style write pattern for saveContacts:

1. Write contacts to a temporary file (/contacts3.tmp)
2. Flush to ensure data is on flash
3. Rename existing /contacts3 → /contacts3.bak
4. Rename /contacts3.tmp → /contacts3
5. Remove /contacts3.bak (no longer needed until next save)

If the write fails mid-save, the .tmp file is removed and the original contacts file is left untouched.

On load, if /contacts3 is missing or empty, loadContacts falls back to /contacts3.bak automatically. This covers the edge case where power is lost between steps 3 and 4.

Platform guard: Only enabled on devices with sufficient flash for the temporary file (~2x contacts storage during save). Disabled on NRF52 unless EXTRAFS or QSPIFLASH is defined.

---

Build firmware: Build from this branch

[weebl2000]

I think what actually caused the contacts to miss in the first place was the nodeinfo files that were written regardless of auto-add contacts.

[winnieXY]

Hey, I'm working on something similar for the repeater - however as far as I know the rename is atomic - thus there is no need to create a .bak file in my eyes.

[syssi]

This fixes a real and reproducible data loss path. Confirmed on a Seeed Xiao S3 WIO (ESP32-S3), env Xiao_S3_WIO_companion_radio_wifi, with ~350 contacts, related to #1519.

The current saveContacts() opens /contacts3 with openWrite("w"), which truncates the file to 0 bytes before the rewrite even starts. If anything goes wrong during the rewrite of ~53 KB (350 * 152 bytes), the contact list is gone. On my device the trigger was a nearly full SPIFFS (1312 of 1404 KB used, see #1519/#1601): the truncate frees the old file, the rewrite then fails on the full fragmented filesystem, and /contacts3 is left at 0 bytes. At the next boot loadContacts reads it as empty (loaded=0) and the first sync makes the loss permanent. So it is not only power loss that hits this, a failing write does too.

I implemented the same atomic tmp + rename pattern independently and it stops the wipe:

saveContacts: OK wrote=350 contacts
reboot
loadContacts: file_size=53200 bytes, loaded=350

Contacts now survive the reboot. The extra .bak retention and the load time fallback to .bak in this PR are a good addition. They cover the power loss window between renaming /contacts3 to .bak and renaming .tmp to /contacts3, which a plain tmp + rename does not fully cover. Worth pairing with #1601 so an already full device first gets enough free space for the temporary file.