Avoid competing duplicate early Email folder initialization on iOS

[thesnoopy]

Summary

This PR fixes a reproducible iOS Mail initial sync issue for Email folders where a second very-early fresh initialization of the same folder can arrive shortly after the first initial sync has already started making progress.

Before this change, that second early initialization could become a competing sync path instead of following the already active initial sync state. In practice this could lead to loop detection, item-by-item fallback, stalled or trickling visible progress, and generally unstable early folder sync behavior.

This PR does not disable loop detection globally.

Instead, for a narrowly scoped case only, it attaches a duplicate very-early reqkey='0' Email folder initialization to the already running initial sync state for the same folder.

Problem

Observed with iOS Mail / ActiveSync on Email folders:

• the first initial sync starts normally
• shortly afterwards, a second fresh init of the same Email folder may arrive
• this creates a competing early sync path instead of a continuation of the active one
• the result can be:
  • loop detection
  • fallback to one-by-one export
  • slow/trickling visible sync in the UI
  • or otherwise unstable early sync behavior

In live testing this was especially visible during early sync of a large Email folder. Once the duplicate early initialization was attached to the already active sync state, normal batched sync progress resumed.

Root cause

The issue did not behave like a permanently broken message or a general IMAP export failure.

The observed behavior was instead consistent with an early duplicate initialization of the same Email collection:

• first initial sync begins and starts making forward progress
• a second very-early fresh initialization for the same folder arrives
• Z-Push previously treated that as a separate fresh path
• that could push the folder into loop-like behavior even though the original sync had already started progressing correctly

The fix therefore addresses sync-state handling at the request boundary rather than weakening loop protection globally.

Fix

In src/lib/request/sync.php, when a request arrives with reqkey='0', Z-Push now checks whether this is a very-early duplicate initialization of the same Email folder and whether there is already an active initial sync state for that folder that recently made progress.

If so, the duplicate early request is attached to the already active sync key instead of creating a competing fresh initialization path.

This keeps the second early request aligned with the active sync state rather than letting it establish a separate competing startup path.

Why multiple files are changed

Although the functional core of the fix is centered around the early duplicate-init attach path in src/lib/request/sync.php, the full patch touches several related files because the final working state was reached through investigation and then cleaned up.

Current purpose of the changed files:

• src/lib/request/sync.php

  • contains the actual functional fix
  • attaches a very-early duplicate reqkey='0' Email folder initialization to the already active sync state for that folder

• src/lib/core/loopdetection.php

  • removes the previously tested but failed grace/suppression-only mitigation
  • keeps normal loop detection behavior intact

• src/backend/imap/imap.php

• src/lib/core/streamimporter.php

• src/lib/default/diffbackend/diffstate.php

• src/lib/default/diffbackend/exportchangesdiff.php

  • these files were part of the investigated/final tested working tree
  • diagnostic-only instrumentation was removed before opening this PR
  • no temporary debug-only logging is intended to remain in the final patch

Scope / safety

The behavior change is intentionally narrow:

• only affects reqkey='0' requests
• only affects Email collections
• only applies when there is already a recent active initial sync state for the same folder
• does not disable general loop detection
• does not weaken normal broken-item handling globally
• does not change the general IMAP parsing/export model
• leaves unrelated sync paths unchanged

What this PR does not do

This PR does not:

• disable loop detection globally
• special-case one concrete folder id
• special-case one concrete message id range
• add mailbox-content workarounds
• redesign the sync engine

It only hardens the very-early duplicate Email folder initialization case.

Reproduction pattern

This was reproduced with a real iOS Mail client against ActiveSync:

1. open/sync an Email folder
2. first initial sync starts and begins making progress
3. shortly afterwards, a second fresh initialization of the same Email folder arrives
4. before this fix:
   • competing early path / loop-style behavior could occur
   • visible sync could trickle or stall
5. after this fix:
   • the duplicate early init is attached to the already active sync state
   • normal batched sync progress continues

Validation

The patch was validated against live iOS Mail behavior.

Observed after the fix:

• large Email folder sync progressed normally in batches
• no immediate fallback into the previous early competing path behavior
• visible folder progress resumed normally
• the previous unstable early-start behavior was no longer reproducible in the tested case

Notes

This PR is intended as a narrow server-side hardening for iOS Mail duplicate early Email folder initialization.

The goal is not to work around arbitrary client behavior in general, but to prevent a specific early duplicate-init pattern from becoming a competing sync path while preserving normal loop protection.