Mission Dialog UX Improvements

[TX-RX]

Description

The mission create/edit dialog has several UX issues that cause confusion and potential data loss.

Issue 1: Incorrect Button Text After First Edit

Current Behavior:
After editing a mission once, all subsequent "New Mission" dialogs show "Edit Mission" button instead of "Create Mission" or "Add Mission".

Root Cause (src/pages/Missions.tsx:438):

// Line 59: State initialized correctly
const [addEditTitle, setAddEditTitle] = useState(t("Add Mission"));

// Line 158: When editing, changes to "Edit Mission"
setAddEditTitle(t("Edit Mission"));

// Line 438: Opens create dialog but NEVER resets title!
onClick={() => {
    setShowAddMission(true);
    setMissionProperties({...});  // Resets properties ✓
    setSelectedGroups([]);         // Resets groups ✓
    // ❌ MISSING: setAddEditTitle(t("Add Mission"));
}}

// Line 436: Button uses stale variable
<Button onClick={() => {add_mission()}}>{addEditTitle}</Button>

Bug Flow:

1. User clicks "New Mission" → Dialog opens → Button = "Add Mission" ✓
2. User clicks "Edit" on existing mission → Button = "Edit Mission" ✓
3. User clicks "New Mission" again → Button STILL "Edit Mission" ❌

Proposed Fix:

// Line 438: Add missing title reset
setShowAddMission(true);
setAddEditTitle(t("Add Mission")); // ← ADD THIS LINE
setMissionProperties({...});
setSelectedGroups([]);

Issue 2: No Unsaved Changes Warning

Current Behavior (src/pages/Missions.tsx:396):
Dialog closes immediately on outside click or ESC without warning, losing all unsaved changes.

<Modal opened={showAddMission} 
       onClose={() => {setShowAddMission(false);}}  // ❌ No warning!
       title={addEditTitle}>

Proposed Fix:

const [isDirty, setIsDirty] = useState(false);

function handleFieldChange(field, value) {
  setIsDirty(true);
  setMissionProperties({...missionProperties, [field]: value});
}

function handleClose() {
  if (isDirty) {
    // Show confirmation dialog
    setShowUnsavedWarning(true);
  } else {
    setShowAddMission(false);
  }
}

<Modal opened={showAddMission} onClose={handleClose} ...>

Issue 3: No Password Removal UI

Current Behavior (src/pages/Missions.tsx:434):
Only has text input - no "Clear Password" or "Remove Password" button.

<PasswordInput 
    defaultValue={missionProperties.password} 
    onChange={e => { missionProperties.password = e.target.value; }}
/>

Note: Backend API supports DELETE /Marti/api/missions/<name>/password, but UI doesn't expose it.

Proposed Fix:

<PasswordInput 
    value={password} 
    onChange={setPassword} 
    label="Password (optional)"
    rightSection={
        password && <IconX onClick={clearPassword} style={{cursor: 'pointer'}} />
    }
/>

Or add explicit button:

<Button variant="subtle" onClick={removePassword}>Remove Password</Button>

Steps to Reproduce

Issue 1:

1. Click "New Mission" → Note button says "Add Mission"
2. Close dialog
3. Click Edit on any mission → Note button says "Edit"
4. Close dialog
5. Click "New Mission" again → Bug: Button still says "Edit"

Issue 2:

1. Click "New Mission"
2. Enter mission name, description, etc.
3. Click outside dialog or press ESC
4. Observe: All changes lost without warning

Issue 3:

1. Edit mission that has a password
2. Try to remove password completely
3. Observe: Can only change to different password, cannot remove

Files to Change

• src/pages/Missions.tsx - All three issues in same component

Priority

• Issue 1: Low (cosmetic, but confusing)
• Issue 2: Medium (can cause data loss frustration)
• Issue 3: Low (conditional on keeping password feature)

[Knobee]

PR #181 addresses Issues 1 and 2.

Issue 3 needs backend work and was deferred:

• The DELETE /Marti/api/missions/<name>/password endpoint cited in the issue requires a Data Sync token or iTAK client certificate (mission_marti_api.py:754-783) and isn't callable from the admin web UI.
• The /api/missions POST handler ignores password: "" on create (mission_api.py:103: if key == "password" and request.json.get("password")).
• The PUT/edit branch would set password="" but never recomputes password_protected, leaving stale state in the DB.

Issue 3 should be split off as a separate UI + backend change — the backend needs either a new admin-authenticated DELETE /api/missions/<name>/password route, or the existing handler taught to honor explicit password clears.