feat(local): concurrent frame transcription for local models

[julio4]

Local batch processing describes screenshots one at a time; roughly 15 sequential describe_frame vision calls per batch, which dominates transcription time. This PR makes that concurrency configurable so users whose local server can handle parallel requests can run several frame descriptions in flight and cut transcription time.

Opt-in: the default is 1 (today's sequential behavior), so nothing changes unless the user raises it.

Changes

• New setting llmLocalMaxConcurrency (Int, default 1, clamped to 1…16), read by OllamaProvider.maxConcurrency.
• Parallel frame description: OllamaProvider.transcribeScreenshots now runs describe_frame calls through a bounded withTaskGroup (up to maxConcurrency in flight), re-sorting results by timestamp. The dependent segment → summary → title chain is untouched (it can't be parallelized).
• Settings UI: a "Max concurrent requests" stepper (1–16) in Settings → Providers, shown only for the local provider, wired through ProvidersSettingsViewModel.
• OllamaProvider marked @unchecked Sendable so the task-group closures can capture it (effectively immutable; let endpoint + UserDefaults reads), matching the existing convention (StorageManager, ScreenRecorder).

Why manual setting

The local server's concurrency limit isn't exposed over HTTP: LM Studio reports model state/quant/context via /api/v0/models but not "Max Concurrent Predictions", and Ollama's parallelism is the OLLAMA_NUM_PARALLEL env var. So Dayflow can't detect it; the user sets it to match their server (keep it ≤ the server's own limit; going higher just queues server-side).

Notes / expectations

• Speedup is GPU-bound. N concurrent is not N× throughput; on a healthy setup transcription typically drops ~1.5–2.5×.
• Only the independent describe_frame calls are parallelized.

Risk / scope

• Opt-in; no behavior change unless the setting is raised above 1.
• Contained to the local-provider transcription path + its settings UI.