bug(calendar): --remove-zoom leaves description block when description was Zoom-only

[alexisperumal]

Summary

gog calendar update --remove-zoom on an event whose description contains only the gog-managed Zoom block leaves the description block intact, even though the Zoom meeting is correctly cancelled on Zoom's side. Recipients of the event would still see a clickable "Join Zoom Meeting" link pointing at a now-cancelled meeting.

The bug surfaces only when the gog-managed Zoom block is the entire description. Events that have additional user content before/after the block work correctly (block stripped, surrounding content preserved).

Repro (against main, 5afc19f)

# 1. Create an event with --with-zoom (description is the Zoom block only)
gog calendar create primary \
  -a <your-acct>@gmail.com \
  --summary "Repro" \
  --from "<future-time>" --to "<future-time + 30m>" \
  --with-zoom \
  --json | jq -r '.event.id'  # capture EVENT_ID

# 2. Verify the description contains only the gog-zoom-meeting block
gog calendar event primary $EVENT_ID -a <your-acct>@gmail.com --json | jq -r '.event.description'

# 3. --remove-zoom
gog calendar update primary $EVENT_ID -a <your-acct>@gmail.com --remove-zoom

# 4. Re-fetch and observe: description still contains the Zoom block, but the
#    Zoom meeting is cancelled on Zoom's side (audit line confirmed action=delete)
gog calendar event primary $EVENT_ID -a <your-acct>@gmail.com --json | jq -r '.event.description'

Expected: description becomes empty (or whitespace-only).
Actual: description unchanged; still contains the gog-zoom-meeting block referencing the cancelled meeting.

Reproduces 100% of the time on macOS, against main HEAD 5afc19f, against a consumer Gmail account.

Differential (verified)

Test setup	--remove-zoom result
Event description was only the gog-managed Zoom block	❌ Block remains; description unchanged
Event description had user content + the gog-managed Zoom block	✅ Block stripped; user content preserved

Root cause (suspected)

In internal/cmd/calendar_edit.go, the --remove-zoom path at ~line 973 correctly produces an empty description via:

patch.Description = applyZoomDescriptionBlock(descriptionForPatch(existing, patch), "")

But the subsequent merge at calendar_edit.go:994-996 treats empty as "no change requested":

if strings.TrimSpace(patch.Description) != "" {
    merged.Description = patch.Description
}

When the post-strip description is empty (only-Zoom-block case), this branch is skipped and the existing description survives the merge.

This is a pre-existing patch-merge gap that the new description-mode path exposes — not a regression introduced by #590. The TrimSpace != "" check is reasonable for "user didn't pass --description" cases but doesn't differentiate from "user wants description cleared," which --remove-zoom newly relies on.

Suggested fix direction

Distinguish between "user didn't set description" and "user wants description cleared." The Google Go client uses ForceSendFields for forcing zero-value strings (vs NullFields for pointer/struct fields), so the likely candidate for clearing the Description string field is patch.ForceSendFields = append(patch.ForceSendFields, "Description") when the post-strip result is empty AND we know we intend to clear (e.g., --remove-zoom path).

For reference, the legacy ConferenceData clearing at line 974-977 uses NullFields correctly — but that's because ConferenceData is a pointer-to-struct, not a string:

if existing != nil && existing.ConferenceData != nil && isZoomConferenceData(existing.ConferenceData) {
    patch.ConferenceData = nil
    patch.NullFields = append(patch.NullFields, "ConferenceData")
}

So the Description field needs analogous intent (force-clear), but via the string-appropriate ForceSendFields mechanism.

Impact

• Functional: users running --remove-zoom may believe the Zoom info is gone from the event, but recipients still see the (now-dead) Zoom link in the event description
• Data hygiene: stale Zoom URLs persist in Calendar events long after the meetings are cancelled
• Audit trail mismatch: the [zoom] action=delete audit line claims success; the Calendar-side state contradicts it

Discovered during

Live-capture validation of PR #590 against real Zoom Pro + real Google Calendar (consumer Gmail). Same setup used to validate the original architecture finding that drove the description-mode pivot. Test infrastructure still in place; happy to re-test any proposed fix against the same setup.

[alexisperumal]

Confirmed real-world user-visible impact — clicking the now-stale Zoom link from the Calendar event produces this error:

[alexisperumal]

Calendar UI shows the link as live and clickable; Zoom side knows the meeting was deleted. Recipient gets the dialog above. The "Recover" button is a Zoom host-side feature — not actionable for a regular attendee.

Severity in our use case: low (rare edge case — events with description containing only the gog-managed Zoom block). Likely high if anyone scripts --with-zoom create + --remove-zoom cancel as a "cancel this Zoom meeting" pattern without re-checking the event description.

[alexisperumal]

Real-world scope clarification + correction on a hypothesis

After thinking through when this bug actually fires in practice, two scenarios:

Case A — whole event being cancelled: The right tool is gog calendar delete <event-id>, which deletes the entire event (description and all). This bug never enters the picture.

Case B — event still happening but the Zoom portion is being removed (switch Zoom→Meet, drop video conferencing while keeping in-person, share event with someone who doesn't need the Zoom link, etc.): --remove-zoom is the right tool, and this is where the bug bites. The original event persists with a now-dead Zoom link in the description.

So real-world severity is mostly bounded to "edit-not-delete" workflows where Zoom is being removed but the event itself persists — naturally rarer than full cancellations. Recipients still see a "Join Zoom Meeting" link that produces the "Unable to start this meeting / This meeting has been deleted" dialog when clicked.

Hypothesis I want to retract

I'd initially also assumed a follow-on --with-meet (e.g., switching Zoom→Meet via --remove-zoom then --with-meet) would be blocked by the cross-provider check at extractZoomMeetingID returning the marker-based ID, causing a deadlock until manual description-editing. Tested it. Wrong. The cross-provider check is asymmetric:

• --with-zoom on event with existing Meet/Zoom → check fires (rejects with usage(...))
• --with-meet on event with existing Zoom description block → check does NOT fire (succeeds)

After --with-meet on the same buggy event, the result is: working Meet conferenceData attached + stale Zoom description block still present. No deadlock — but recipients see both a Google Meet button AND a dead Zoom link in description, which is confusing UX even if functionally only Meet works.

May be intentional asymmetry (description-mode Zoom is "below" first-party Meet in the precedence model). May be an oversight in symmetric guard logic. Flagging in case it's the latter; not asking for a separate issue.

Net severity assessment

The original bug stands as filed. Real-world frequency lower than my initial framing suggested (Case A users not affected), but Case B users do hit it and the result is a visible dead link to recipients. The asymmetric check observation is a side note, not load-bearing.