fix(office): probe star-office preferred_url host as given

[lornestack]

Summary

• StarOfficeDetector::build_candidate_urls extracted only the port from preferred_url and constructed every candidate as http://localhost:{port}. On remote deployments (aionui --remote, browser on another machine) detection silently "succeeded" against the server-local interface and the returned http://localhost:19000 overwrote the user's configured address — the Star Office half of [Bug]: 公网无头服务器部署：可视化办公室 URL 和文件预览硬编码 localhost，远程访问下功能不可用 AionUi#3212.
• Keep the caller-supplied {scheme}://{host}:{port} as candidate 0 (path/trailing slash stripped), in both scan and exact modes. The localhost known-port/±radius expansion is unchanged.
• Pick scan winners by candidate order instead of completion order, so the preferred URL beats an equivalent localhost candidate that responds a few milliseconds earlier.

Reproduction (before)

With a Star Office mock bound to 0.0.0.0:19000:

POST /api/star-office/detect {"preferred_url":"http://192.168.1.27:19000","force":true}
→ {"success":true,"data":{"url":"http://localhost:19000"}}     # host discarded
mock log: probed from 127.0.0.1 only, never contacted 192.168.1.27

After:

→ {"success":true,"data":{"url":"http://192.168.1.27:19000"}}  # verbatim
mock log: GET /health, /status, / from 192.168.1.27

Test plan

• New unit tests: remote host preserved (scan + exact modes), path/trailing slash stripped
• New integration test: detect returns a healthy preferred URL verbatim even when the equivalent localhost candidate is also reachable
• cargo test -p aionui-office — all green (134 unit + integration suites)
• cargo fmt --check, cargo clippy -p aionui-office -D warnings
• E2E against the real backend (aioncore behind AionUi webui --remote): detect now returns the user-supplied address