Perf: Defer file tags database scan off the startup UI path

[woojh3690]

Resolved / Related Issues

• Related to Bug: Empty file tag registry keys accumulate and block startup #18616
• Related to Bug: Files hangs for minutes on start querying registry #17678

Why this change is needed

InitializeAppComponentsAsync() resumes on the UI context after quick access initialization and then calls UpdateTagsDb() synchronously. That method recursively enumerates the registry-backed tag index and validates every entry against its FRN, path, and alternate data stream. The work is maintenance rather than a prerequisite for showing the main window.

What changed

• Run the tag database scan after the existing non-critical background initialization instead of blocking the UI thread.
• Execute the scan from finally so a failure in another background initializer does not silently skip tag maintenance.
• Log failures from the fire-and-forget initialization task.
• Serialize registry path/FRN index operations and ADS writes because they are multi-step updates and can now overlap with user actions.
• Keep each scanned item atomic rather than locking the entire scan, avoiding a long wait if the user applies a tag while maintenance is running.
• Update paired database and ADS writes through one helper and show write-error UI only after releasing the lock.

This does not change the registry schema or stored tag format.

Steps used to test these changes

1. Built src\Files.App\Files.App.csproj for Debug x64 without packaging.
2. Built and signed the Release x64 sideload MSIX bundle with the same package settings used by CI.
3. Verified the generated MSIX bundle signature successfully.
4. Built tests\Files.InteractionTests\Files.InteractionTests.csproj for Release x64.
5. Built the parent commit (af9128ecc) as FilesDev 4.1.4.1 and this PR (b98e185a7) as FilesDev 4.1.4.2. Both packages used the same FilesDev identity.
6. Before every launch, restored the same registry snapshot containing 276,160 empty path-index keys and 95,340 empty FRN-index keys, with zero value-bearing tag records.
7. Ran three 20-second cold-launch trials per build. UI responsiveness was probed every 50 ms with SendMessageTimeout(WM_NULL).

Median of three trials	Parent commit	This PR
Window handle created	0.72 s	0.76 s
Longest UI-unresponsive interval	5.19 s	0.30 s
Process CPU during first 20 s	19.72 s	19.84 s
Peak working set	787.1 MB	738.7 MB

The controlled A/B test confirms that the PR reduces the longest UI stall by 94.1% with the same package identity and registry data. CPU time is effectively unchanged, confirming that the scan is deferred rather than eliminated.

There are currently no focused unit tests for the registry-backed FileTagsDatabase; the synchronization paths were additionally reviewed against all current SetTags, UpdateTag, GetAll, import, export, and ADS write call sites.

Status / Follow-up investigation

Further investigation after opening this draft found that the affected user had never assigned a file tag, but the stable package registry hive contained 276,160 empty path-index keys and 95,340 empty FRN-index keys, with zero value-bearing tag records. Normal item loading calls SetTags() with an empty tag array, and the current registry implementation creates path and FRN keys before removing values, so ordinary browsing can grow an empty tag index indefinitely. The full code-path analysis and hive measurements are documented in #18616.

The controlled A/B test above confirms that this PR genuinely mitigates the visible startup freeze, rather than only appearing faster because a Dev package uses a clean registry hive. However, it does not prevent empty-key accumulation or reduce the scan's CPU cost. The root cause in #18616 should be addressed first; this draft can then be evaluated separately to determine whether background maintenance is still needed.

Note: This pull request was created with the assistance of AI.

[yair100]

@woojh3690 we don't mind if contributors use AI in their work, but only if they already have a solid understanding of the codebase. Considering this is your first PR, it would be advisable to first learn your way around the codebase. As a sidenote, we need some time to review the linked issue to make sure we can reproduce the issue on our end.

[woojh3690]

@yair100 I completely understand. While I do think I reviewed it thoroughly, I also don’t particularly want this PR to be merged. It’s just that, in my environment, this issue has been quite annoying and has made Files very slow. I initially tried to solve it personally, even if that meant forking the project with the help of AI, and that eventually led me to open this PR. If there’s anything I can do to help reproduce the issue, please feel free to ask at any time.

Additionally, I’ll add a note to the main text mentioning that it was written with the help of AI.