Perf: scope handler runtime-cache per operation (#5) + skip clean-up scan on flat+guid (#3)

[KevinJump]

Follow-up to #989. Implements items #3 and #5 from the performance review. (#1 batched save is still parked for its own deeper investigation.)

---

#5 — runtime-cache scope keyed by managed thread id

GetCacheKeyBase() built its runtime-cache key from Environment.CurrentManagedThreadId:

=> $"keyCache_{this.Alias}_{Environment.CurrentManagedThreadId}";

This backs the per-folder key cache (GetFolderKeysAsync) and the child-item cache (GetChildItemsAsync). Because it uses the OS thread id, across an await a continuation can resume on a different thread, so mid-operation the key changes:

• Cache misses — subsequent lookups compute a different key and re-hit entityService instead of the cache.
• Leaks — the end-of-operation cleanup (CleanCaches) runs on whatever thread it lands on and clears that thread's key prefix, so entries created under other thread ids are never evicted from the shared, app-wide runtime cache.

Fix

Replace the thread id with an AsyncLocal<string> scope id that flows with the async operation (stable across thread hops):

• PrepCaches/CleanCaches (import + report) now begin/end a scope via BeginCacheScope/EndCacheScope.
• Top-level ExportAllAsync establishes its own scope (its child-item lookups were previously thread-keyed too).
• ImportAllAsync and ReportAsync run the cleanup in a finally, so entries are released even on exception.
• Callers with no active scope (paged import/report, ad-hoc tree/dependency lookups) fall back to the thread id — behaviour there is unchanged, so the paged PreCacheFolderKeysAsync optimisation is untouched.

The cache key captured at BeginCacheScope is reused for the clear, so cleanup targets the right entries regardless of which thread finally runs on.

#3 — skip the CleanUp folder scan for flat + guid-name setups

On every save/move/delete (ExportOnSave), SyncHandlerRoot.CleanUpAsync recursively reads the whole handler folder tree, parsing each file, to find duplicate files to mark as renames. With a flat structure and guid file names an item's file is always {key}.{ext} in the same folder — it never changes name or location — so there is never anything to clean.

ContentHandlerBase (Content/Media, the big trees) already short-circuits this exact case. This PR adds the same early return to the base handler so the settings / level / container handlers (doctypes, datatypes, templates, dictionary, domains, languages, webhooks) also skip the scan when configured flat+guid.

---

Safety / behaviour

• No public API or interface changes.
• Unscoped call paths keep the previous thread-id behaviour (explicit fallback), so paged import/report and tree/dependency lookups are unaffected.
• The flat+guid skip mirrors a trade-off already made in ContentHandlerBase (a full export still reconciles any stale files from a config change).

Testing

• dotnet build clean.
• uSync.Tests: 137 passed, 0 failed.

Follow-ups (noted, not in this PR)

• The paged ImportPartialAsync/ReportPartialAsync flows still use the thread-id fallback; giving them an explicit operation scope would need a small ISyncHandler surface addition.
• Architecture : using compositions and resolvers? #1 (batched content/media save) remains deferred pending Umbraco batch-save testing.

🤖 Generated with Claude Code