feat(asap-tools): parse ms-suffixed Prometheus scrape-interval durations in experiment harness

[milindsrivastava1997]

Background

Split out of #398 during planning. #398 renames the planner/engine's time fields to explicit _ms units to support sub-second scrape intervals, and fixes the Python experiment harness (asap-tools/experiments/) so it doesn't silently misinterpret the new ms values. That lockstep fix keeps experiment_utils/config.py::get_prometheus_scrape_interval() parsing seconds/minutes only — it does not add new capability.

This issue is the additive follow-up: actually let users express a sub-second scrape interval (e.g. "100ms") through the experiment harness, end to end.

Work

• experiment_utils/config.py::get_prometheus_scrape_interval() — rename to get_prometheus_scrape_interval_ms(), parse Prometheus-native ms-suffixed duration strings (e.g. "100ms") and return milliseconds. Check the ms suffix before the s suffix — "100ms" and "15s" both match endswith("s"), so a naive check misroutes "100ms" into the seconds branch and crashes on int("100m").
• Propagate the ms value through label_discovery_wait in experiment_run_e2e.py, experiment_only_ingest_path.py, experiment_run_grafana_demo.py — convert to fractional seconds at the time.sleep() call sites rather than sleeping 1000x too long.
• Propagate through the CLI arg passed to the asap-planner-rs binary (depends on feat(asap-planner-rs): add millisecond precision support for sub-second scrape intervals #398's CLI flag rename landing first).

Why split from #398

Additive, not correctness-coupled with the Rust rename — nothing breaks if this ships after #398. Keeping it separate keeps #398's diff focused on "don't break under the rename" rather than "add a new harness capability."

See .design_docs/issue-398-millisecond-precision-plan.md ("Follow-up Issues" section) for full detail.