fix(embeddings): make the HTTP lane read timeout configurable

[MummIndia]

Summary

The 10s read budget holds for a warm endpoint — embedding a short string does return in
well under a second, as the comment says. But the FIRST call after a cold start also
pays for loading the embedding model into memory, and on a modest or busy machine that
is comfortably past 10s.

The failure is silent, which is the part worth fixing. The timeout fires, the lane
produces no vectors, its collection stays empty, and retrieval degrades to whatever
other lane happens to be populated. Nothing marks the endpoint as the cause, so the
symptom shows up much later as poor retrieval quality rather than as an embedding error
— in our case French queries ranking badly because only the English-only fallback lane
had any content.

Adds EMBEDDING_TIMEOUT alongside the existing EMBEDDING_BATCH_SIZE and
EMBEDDING_MAX_CHARS, floored at 1s. The default is unchanged at 10s.

Target branch

• This PR targets dev, not main.

Linked Issue

Fixes #5775

Type of Change

• Bug fix (non-breaking — fixes a confirmed issue)

Checklist

• I searched open issues and open PRs — this is not a duplicate.
• This PR targets dev
• My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
• I actually ran the app (docker compose up) and verified the change works end-to-end.

How to Test

1. Point the HTTP embedding lane at a local endpoint whose model is not resident, so the
   first call must load it.

2. Before — the lane's collection stays at 0 entries with no error logged, and
   retrieval silently uses the other lane.

3. Set EMBEDDING_TIMEOUT=60 and reindex. The lane populates.

4. Confirm the default and the floor:

   max(1.0, float(os.getenv("EMBEDDING_TIMEOUT", "10")))   # 10.0 unset, 1.0 when set to 0

Visual / UI changes

None. src/embeddings.py only — an HTTP client timeout.