[Bug]: Auto-archived tasks can remain on Google Calendar after restart or archive-folder move

[martin-forge]

Bug Description

There is still a residual Google Calendar cleanup bug for auto-archived tasks, separate from the issue fixed in #1695.

Summary

A task can be auto-archived successfully while its Google Calendar event remains visible when either:

1. Obsidian was closed when the auto-archive deadline passed, so queue processing runs on next startup before Google Calendar sync is ready.
2. The task is moved into the archive folder, but the retry queue still references the old pre-move path.

This leaves archived tasks still showing in Google Calendar.

Related issue

Related to #1695, but not a duplicate.

#1695 fixed archive-time delete reliability when the delete attempt runs and fails. This issue is about the retry path still being able to lose cleanup work across startup timing and archive-folder moves.

Environment

• TaskNotes 4.5.0+
• Obsidian desktop
• Google Calendar export enabled
• A completed status configured with autoArchive: true
• moveArchivedTasks: true makes the path problem more obvious

Steps to reproduce

Case 1: Startup timing

1. Enable Google Calendar export and auto-archive for a completed status.
2. Create a scheduled task so it syncs to Google Calendar and gets a googleCalendarEventId.
3. Mark the task done.
4. Close Obsidian before the auto-archive queue is processed.
5. Re-open Obsidian after the auto-archive deadline has passed.
6. Check whether the task is archived locally and whether the Google event still exists.

Case 2: Archive-folder move

1. Enable moveArchivedTasks with an archive folder.
2. Create a scheduled task so it syncs to Google Calendar and gets a googleCalendarEventId.
3. Mark the task done and let auto-archive run.
4. Force the first Google delete attempt to remain pending or fail.
5. Let the retry path run.
6. Check whether retry cleanup can still find the archived task after it moved folders.

Expected behavior

• Auto-archive queue items should remain pending until Google cleanup actually becomes possible.
• If the task is moved into the archive folder, retry cleanup should use the archived path rather than the old pre-archive path.
• Archived tasks should disappear from Google Calendar once cleanup succeeds.

Actual behavior

• The auto-archive queue currently starts processing before Google Calendar initialization completes on startup.
• If cleanup is still needed but the calendar sync service is not ready yet, queue items can be treated as processed too early.
• If a task moved from the tasks folder into the archive folder, the queued retry item can still hold the old path, so later retries cannot find the task.
• Result: the task is archived locally but still visible in Google Calendar.

Suspected cause

1. Auto-archive starts before calendar sync is ready

autoArchiveService.start() runs during post-layout initialization before lazy Google Calendar initialization and before taskCalendarSyncService is created.

That means queue processing can happen at startup before Google Calendar cleanup is actually available.

2. Retry queue still keys off the old task path

AutoArchiveService.processItem() looks up tasks using item.taskPath.

When toggleArchive() moves a task into the archive folder, the task path changes. The retry item is kept pending, but its taskPath is not updated to the new archived path.

On the next retry pass, lookup by the old path can return null, so the item is dropped even though Google cleanup never happened.

Why this matters

This breaks the main promise of auto-archive for Google Calendar users: tasks older than the configured archive delay can still clutter the calendar, even though they have already disappeared from the task list.

Suggested fix

• Keep queue items pending when Google cleanup is still required but calendar sync is not initialized or not yet ready.
• Update the queued taskPath to the archived path when archiving succeeds but calendar cleanup remains pending.
• Add regression tests for:
  • cold-start processing before Google Calendar initialization
  • second-pass retry after a task moved from the tasks folder to the archive folder

Happy to test a fix.

[martin-forge]

Additional evidence from my live vault after checking the actual TaskNotes config and archived task files:

• moveArchivedTasks is definitely enabled (TaskNotes/Archive)
• done is configured with autoArchive: true and autoArchiveDelay: 1440
• Google Calendar export is enabled and syncOnTaskDelete is enabled
• multiple archived tasks still retain googleCalendarEventId
• those stale archived tasks are no longer present in autoArchiveQueue

For the specific lingering March/April task events I checked, the moved-path retry bug now looks like the likeliest root cause:

1. auto-archive ran while Obsidian was already open
2. the task moved from TaskNotes/Tasks/... to TaskNotes/Archive/...
3. Google cleanup did not complete on the first pass
4. the retry item still referenced the old pre-move path
5. the next retry could no longer find the moved task, so cleanup state was effectively lost and the Google event remained

So I think the startup/readiness case in the issue body is still a valid separate failure mode, but for these real-world stale events the archive-folder move + stale queued path seems to be the stronger explanation.