feat(image): parallelize image_generate batches + serialize FileSyncManager cycles (salvage #33971)

[kshitijk4poor]

Salvage of #33971 by @EndeavorYen — both commits cherry-picked verbatim (authorship preserved); the only conflict was test-file context drift (main deleted 3 stale postprocess tests that sat in the hunk's context; resolution keeps only the PR's new test).

What this does for users

1. image_generate joins _PARALLEL_SAFE_TOOLS: when the model requests several images in one turn, they generate CONCURRENTLY instead of one-after-another. Generation latency is network-bound (seconds per image), so a 4-image batch completes in ~1× single-image latency instead of ~4×.
2. Worker cap is configurable via image_gen.max_parallel_requests in config.yaml (default 4, clamped 1..8) — follows the documented convention that image_gen is an intentionally-absent DEFAULT_CONFIG root; documented in the website image-generation docs.
3. Fixes a REAL race the parallelism would otherwise widen: FileSyncManager.sync()/sync_back() had no in-process serialization (the existing fcntl.flock is cross-process, sync_back-only, and a no-op on Windows). Concurrent artifact syncs could drop files from _synced_files (lost update). Now serialized by a threading.Lock.

Verification

• 21 passed (test_file_sync.py + test_image_generation_artifacts.py + new test_image_generate_parallel.py)
• MUTATION-VERIFIED: reverting only the file_sync lock makes both new concurrency tests fail with the real lost-update (second.png dropped from _synced_files) — the tests bind the race, they are not change-detectors
• Parallel-safety of the handler traced end-to-end: per-task-env FileSyncManager (covered by the new lock), managed FAL client (already lock-guarded, httpx thread-safe), filename collisions impossible (<prefix>_<ts>_<uuid4[:8]>), config read is mtime-cached (stat + deepcopy per batch, no YAML parse)
• Routing verified: 2+ image_generate calls form one ("parallel", …) segment → _execute_tool_calls_concurrent; mixed batches take the same executor per segment

Honest caveat on the cap: a mixed batch (images + fast reads) shares one worker pool per parallel segment, so max_parallel_requests: 1 serializes unrelated tools in that segment — blunt but user-opted-in and clamped ≥1; reads drain in milliseconds through remaining slots at the default of 4.

Closes #33971.