sweep up scrum WARNs — model const, stale config, temp_path entropy, smoke gate

Four findings deferred from the 2026-05-02 scrum, all 1-5 line fixes:

W1 (kimi WARN @ scrum_master_pipeline.ts:1143) — `gemini-3-flash-preview`
hardcoded twice in MAP and REDUCE phases. Extracted TREE_SPLIT_MODEL +
TREE_SPLIT_PROVIDER constants near the existing config block. Diverging
the two would break tree-split coherence (per-shard digests must come
from the same model the reducer collapses).

W2 (qwen WARN @ providers.toml:30) — stale `kimi-k2:1t` reference in
operator-facing comments after PR #13 noted it's upstream-broken. Reframed
as historical context ("was X here pre-2026-05-03 — that model is broken")
so future operators don't paste-route from the comment.

W3 (opus WARN @ vectord-lance/src/lib.rs:622) — temp_path() entropy was
only pid+nanos, which collide under tokio scheduling when multiple tests
in the same cargo process create temp dirs back-to-back. Added per-process
AtomicU64 sequence counter — guarantees uniqueness regardless of clock.

W4 (opus INFO @ scripts/lance_smoke.sh:38) — `|| echo '{}'` swallowed
curl transport failures (gateway down, network broken, timeout), surfacing
as misleading "no method field" jq errors at the next probe. Now captures
$? separately, gates a "curl reachable" probe, and only falls back to
empty body for the dependent jq parse. Smoke went 9 → 10 probes.

Verified: vectord-lance 7/7 tests PASS, gateway cargo check clean,
lance_smoke.sh 10/10 PASS against live gateway.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

crates/vectord-lance/src/lib.rs

@@ -620,13 +620,23 @@ mod tests {
     use super::*;
 
     fn temp_path(label: &str) -> String {
-        let n = std::time::SystemTime::now()
+        // Per-process atomic counter — guarantees uniqueness regardless
+        // of clock resolution or test scheduling. Combined with pid, the
+        // result is unique within and across processes for any practical
+        // test workload. Nanosecond timestamps were not enough on their
+        // own: opus WARN at lib.rs:622 from the 2026-05-02 scrum noted
+        // that under tokio scheduling, multiple tests in the same cargo
+        // process can hit the same nanos bucket.
+        use std::sync::atomic::{AtomicU64, Ordering};
+        static COUNTER: AtomicU64 = AtomicU64::new(0);
+        let seq = COUNTER.fetch_add(1, Ordering::Relaxed);
+        let pid = std::process::id();
+        let nanos = std::time::SystemTime::now()
             .duration_since(std::time::UNIX_EPOCH)
             .map(|d| d.subsec_nanos())
             .unwrap_or(0);
-        let pid = std::process::id();
         std::env::temp_dir()
-            .join(format!("vlance_test_{label}_{pid}_{n}"))
+            .join(format!("vlance_test_{label}_{pid}_{nanos}_{seq}"))
             .to_string_lossy()
             .to_string()
     }