Analytics logging writes continuously and repeats identity errors

Description of Issue

- The bundled analytics SDKs (dunamis, GrowthSDK) write constant trace-level chatter to disk, never clean up their logs, and repeat the same identity error indefinitely

- Even with "Share usage information" turned off, they keep uploading events that carry the device ID and the user ID

Step-by-step Reproduction Instructions

1. In Lightroom, make sure Preferences → General → Privacy → "Share usage information" is off. Check it:
   defaults read ~/Library/Containers/com.adobe.mas.lightroomCC/Data/Library/Preferences/com.adobe.mas.lightroomCC MetricsParticipationChoice
   (prints opt-out)

2. Quit and relaunch Lightroom, then leave it idle for 10 minutes

3. In Terminal, look at the newest dunamis log (one file per launch):
   cd ~/Library/Containers/com.adobe.mas.lightroomCC/Data/Library/Logs/Adobe/com.adobe.dunamis
   F=$(ls -t dunamis-*.log | head -1)
   wc -l "$F"; sleep 60; wc -l "$F"                                    # lines per minute
   grep -c "AEPErrorCode" "$F"                                          # identity errors
   grep "ing.inst.*submit:" "$F" | grep -o "kind=[a-z]*" | sort | uniq -c  # events queued for upload, by stream
   grep -c '"event.device_guid"' "$F"; grep -c '"event.user_guid"' "$F"
   grep -c "cc-api-data.adobe.io/ingest" "$F"                           # uploads

4. List the folder: ls -l; du -sh .

The Expected Result

- Production builds don't trace-log every analytics ingest step, and logs are rotated and pruned

- A failing identity update isn't retried indefinitely

- With usage sharing off, Lightroom uploads no analytics events, or at least none carrying device or user IDs

The Actual Result

- The dunamis log grows by ~150 lines/minute whenever Lightroom is open (median 147, 90th percentile 150; ~210,000 lines on a full day), with bursts around launch. Of 4.58 million lines, 2.2 million are "utl.async begin await / end await" pairs and 1.1 million are "ing.pipeln flush iteration / flush succeeded".

- The log folder is never (or very infrequently) cleaned up: 45 files (one per launch) back to 2026-08-08, 548 MB in total, wasting disk space for log files which are never read

- GrowthSDK identity errors every day (14–36 lines mentioning AEPErrorCode per day), from LogApiManager.cpp updateIdentities: "Identity - ECID: … error: AEPErrorCode"

- 5,729 "fs lock failed" warnings, each followed by a new orphan ingest instance ("ing.orphan start")

- With usage sharing off the whole time (MetricsParticipationChoice = opt-out; com.adobe.dunamis.plist udps_user_tracking_flag = 0), the logs from 2026-08-08 to 2026-11-02 show 4,448 events submitted for upload: 3,398 GrowthSDK "Debug" events and 113 other GrowthSDK events (kind=anon), and 935 dunamis "meta" events (SDK api, cache and lifecycle stats). All 3,513 kind=anon events carry "event.device_guid"; 1,689 carry "event.user_guid". 3,809 uploads to cc-api-data.adobe.io/ingest. No kind=auth events, so account-linked usage tracking does stay off.

- At every launch, in lrcc_console.log: [*** LOG ERROR #0001 ***] [GrowthSDK-…] argument not found [.../dgpcontent/Collection.cpp(257)]

- GrowthSDK's manifest.db (Group Container JQ525L2MZD.com.adobe.GrowthSDK) is among the most-written files

System Details

- Lightroom 9.6 (Mac App Store), build 20260923-1659-a32d844, arm64
- macOS 27.0.1 (26A434), MacBook Pro 16" (MacBookPro18,2), Apple M1 Max, 64 GB RAM
- Cameras: Canon R5m2 and R6m3
- Library: 41,490 photos, 211 albums, 4,818 stacks; local library 78–85 GB (40 GB originals, 29 GB proxies, 12 GB previews); all proxies stored locally, photo cache limit 50 GB
- Working set: an 11,650-photo Canon CR3 shoot