fix/workflow llm provider isolation

[duguwanglong]

isolate workflow LLMClient from session
Provider singleton"). It closes three more concurrency holes that surfaced
during the second-pass review:

A. Cross-loop httpx.AsyncClient reuse (regression risk introduced by the
idempotent reset in 3c7b300d). httpx.AsyncClient binds to whichever
event loop awaits it first. Session runs on uvicorn's main loop; the
workflow runs on the dedicated flocks-workflow-llm-loop. If session
created the client first, workflow inheriting it on a different loop
raises "got Future attached to a different loop" or silently hangs.

_prepare_provider now tracks the owning loop of provider._client
via a module-level WeakKeyDictionary and forces a reset whenever the
workflow loop id differs from the marker — even if the config itself
is unchanged. Same-loop back-to-back calls still reuse the client.

B. Provider._ensure_initialized() lazy init was not thread-safe: the
_initialized flag was flipped before providers_to_register and
_load_dynamic_providers() finished, so a concurrent caller could
take the fast path and observe an empty _providers registry. The
workflow _warmup_llm() helper papered over this for itself but the
session had no such guard — concurrent session/agent boot would hit
"Provider X not found" intermittently.

Now uses double-checked locking with threading.Lock and only flips
_initialized = True after the registry is fully populated.

C. Provider.apply_config() is called on every session step and
inside workflow llm.ask(). Previously each call unconditionally
rewrote provider._config and rebuilt provider._config_models,
causing race-prone reads on the mutable model list across loops.

apply_config is now idempotent: it skips both provider.configure(...)
and the _config_models rebuild when the desired values already
match what the provider holds. Model-list rebuild remains atomic
(build full list then assign) so readers never observe a half-built
list.