Fix property deletion corrupting the in-flight property list

[dkorkmazturk]

deleteProperty rebuilt mrgfpIn by adding the property being deleted (fp) for every retained entry (fp2), so after a successful server-side delete the array held copies of the deleted property and none of the retained ones.

The visible list and exit-time persistence use mRgfpall, so the corruption stayed hidden until a later reset-to-default: deleteDefaultedProperty scans mrgfpIn, and after the first reset in a session it found no existing record for subsequent properties, never telling the server to delete them. Their resets appeared to take effect locally, then reverted on the next load or sync.

Add the retained entry (fp2) instead of the deleted one.

[ericberman]

I think I see the bug: if mrgfpin is [fp1, fp2, fp3] and I delete fp3, I want to rebuild mrgfpin as [fp1, fp2] but I am actually rebuilding it as [fp3, fp3], but I'm not quite clear the repro steps for it to manifest itself - how do I get this incorrect array to ultimately manifest itself in a persisted flight?

[dkorkmazturk]

I was able to reproduce it using these steps:

1. Create a test flight with three custom properties set, called fp1, fp2, and fp3 here. Checkbox properties are easiest: check all three. Save the flight.
2. Go to Recent, refresh, and reopen that saved flight.
3. Tap Edit Flight Properties… and find those properties.
4. Uncheck fp3. Wait for Deleting Property… to finish successfully. This deletes fp3 on the server and corrupts mrgfpIn to [fp3, fp3].
5. Stay on that same Properties screen and uncheck fp2. Leave fp1 checked. The checkbox clears, but no server deletion is requested for fp2.
6. Choose Return to Flight, then Update Flight. Wait for the success confirmation.
7. Go to Recent, refresh, reopen the flight, and inspect its properties.

Expected: only fp1 remains set.
Buggy result: fp1 and fp2 remain set, fp3 is cleared.