fix(cloudflare): protect FLAG_LOG from async request interleaving

[vahidlazio]

Summary

Fixes telemetry data loss and mixing under high request concurrency in the Cloudflare resolver.

CF Workers are single-threaded but handle concurrent async requests within the same isolate, interleaving at await points. The thread_local FLAG_LOG was vulnerable:

1. Request A sets FLAG_LOG, calls req.bytes().await → yields
2. Request B starts, overwrites FLAG_LOG with a fresh default
3. Request A resumes, resolves flags — writes to B's FLAG_LOG
4. Request A hits scheduler.wait(0).await → yields
5. Request B takes FLAG_LOG — gets mixed A+B data
6. Request A resumes — FLAG_LOG is now None, telemetry lost

Fix

• Move FLAG_LOG initialization to after req.bytes().await and right before the synchronous resolve_flags call
• Take FLAG_LOG into a local variable immediately after resolve_flags returns
• The set→resolve→take window is fully synchronous (no await points), so no interleaving is possible
• scheduler.wait(0) and telemetry building operate on the local variable
• Data is put back into FLAG_LOG at the end with no await before handler return

Same treatment for the flags:apply handler.

Context

The old code (pre-#400) used LazyLock<ResolveLogger> with atomics — safe for concurrent async access and batched into periodic checkpoints. PR #400 replaced this with a per-request thread_local RefCell pattern that is not safe across await points.

Test plan

• Deploy to a test Worker and verify telemetry still flows to /metrics and the Confidence backend
• Load test with concurrent requests and verify no telemetry data loss
• Verify resolve responses are unaffected (this only changes the telemetry path)

🤖 Generated with Claude Code