fix(cfapi): FETCH_PLACEHOLDERS infinite loop — ghd_cf_ack_placeholders uses FLAG_NONE instead of DISABLE_ON_DEMAND_POPULATION (#157)

[CCoupel]

Symptôme

Boucle infinie FETCH_PLACEHOLDERS — 1550 appels identiques en quelques minutes:

cfapi: FETCH_PLACEHOLDERS callback ptr=...
[plugin] list /: readdir(112190) returned 5 entries
cfapi: FETCH_PLACEHOLDERS callback ptr=...
[plugin] list /: readdir(112190) returned 5 entries
...

Conséquence : CPU saturé, Explorer bloqué, 0x80070781 sur "Nouveau fichier" (CF state corruption due aux exécutions concurrentes de CfCreatePlaceholders).

Root cause

ghd_cf_ack_placeholders utilise CF_OPERATION_TRANSFER_PLACEHOLDERS_FLAG_NONE (= 0x00000000) dans l'ack CfExecute(TRANSFER_PLACEHOLDERS).

Ce flag laisse le dossier en état "partiellement peuplé" (ENABLE_ON_DEMAND_POPULATION toujours actif). La CF API considère que la population est incomplète → re-déclenche FETCH_PLACEHOLDERS à chaque accès au dossier → boucle serrée.

Le commentaire incorrect /* PlaceholderTotalCount left zero-initialized — signals "population complete" */ dans cgo_cfapi_windows.c induisait en erreur : PlaceholderTotalCount=0 avec FLAG_NONE NE signale PAS la fin de la population.

Le CF API expose CF_OPERATION_TRANSFER_PLACEHOLDERS_FLAG_DISABLE_ON_DEMAND_POPULATION = 0x00000002 exactement pour ce cas.

Fix

Utiliser CF_OPERATION_TRANSFER_PLACEHOLDERS_FLAG_DISABLE_ON_DEMAND_POPULATION dans l'ack.

Les mises à jour remote passent par le sync engine (Watch()/reconciliation), pas par FETCH_PLACEHOLDERS. FETCH_PLACEHOLDERS est prévu pour la population initiale uniquement. Les sous-dossiers convertis avec ENABLE_ON_DEMAND_POPULATION reçoivent chacun leur propre FETCH_PLACEHOLDERS au premier accès ; l'ack avec DISABLE_ON_DEMAND_POPULATION marque chacun comme terminé.

Impact

• Élimine la boucle infinie (1550 appels → 1 appel par dossier au premier accès)
• Élimine la corruption CF causée par les CfCreatePlaceholders concurrents
• Résout la root cause du 0x80070781 persistant sur "Nouveau fichier"