fix(ecstore): keep local path startup fail-fast under Kubernetes (#4640)

The startup topology convergence auto-detection (added in #4631) checked
Kubernetes before endpoint style, so a local path deployment (single or
multi-drive, non-distributed) running inside Kubernetes was classified as
orchestrated with an effectively unbounded wait window. Path-style
endpoints have no hostnames to resolve, so the wait never actually
triggers and runtime behavior is unchanged, but the startup log then
advertised mode=orchestrated / wait_timeout=MAX for a purely local
deployment, which is misleading and contradicts the documented policy
(local path endpoints -> fail-fast).

Order the auto-detection by endpoint style first: only distributed URL
endpoints, which resolve hostnames, pick orchestrated (Kubernetes) or
bounded (otherwise); local path endpoints stay fail-fast regardless of
the platform. Update the doc comment to match and add a policy case
locking Kubernetes + local path to fail-fast.

Co-authored-by: heihutu <heihutu@gmail.com>

crates/config/src/constants/app.rs

@@ -153,8 +153,8 @@ pub const DEFAULT_UNSAFE_BYPASS_DISK_CHECK: bool = false;
 /// - `bounded`: wait for a finite window (see
 ///   `ENV_STARTUP_TOPOLOGY_WAIT_TIMEOUT`) then fail with an actionable error.
 /// - `fail-fast`: fail on the first non-transient resolution error (CI/local).
-/// - `auto`: Kubernetes -> orchestrated, distributed URL endpoints -> bounded,
-///   local path endpoints -> fail-fast.
+/// - `auto`: distributed URL endpoints use orchestrated on Kubernetes and
+///   bounded otherwise; local path endpoints use fail-fast (no DNS to await).
 pub const ENV_STARTUP_TOPOLOGY_WAIT_MODE: &str = "RUSTFS_STARTUP_TOPOLOGY_WAIT_MODE";
 
 /// Environment variable bounding how long startup waits for topology/DNS