Consume centralized DPC "HTTP call done" log line; align actuation baseline

[rubambiza]

Summary

Updates the FMA DPC-log timing pipeline for two coordinated upstream changes in llm-d-fast-model-actuation (both present in its v0.6.0 release):

1. Consume the centralized "HTTP call done" log line. The dual-pods controller replaced its three per-message HTTP-timing log lines with one centralized line discriminated by a purpose field. The parser now keys on purpose tokens: wake → hot-start anchor, create_instance → warm-start anchor, relay_ready → shared readiness end (relay_unready ignored). Cold-launcher timing is unchanged (it comes from a Kubernetes API call, not an HTTP call). Without this, once the upstream change is picked up the parser silently falls back to coarse Kubernetes-timestamp upper bounds and the sub-second wake fidelity goes blank.

2. Align the actuation baseline to container start. The controller's actuation metric now measures from the requester inference-server container's state.running.startedAt rather than the requester pod's creationTimestamp. The harness's Kube-timestamp fallback is realigned to the same baseline so it agrees with the controller.

Closes #1547.

Key change: explicit, non-silent timing source

The single dpc_timing_available boolean is replaced with a per-iteration timing_source. The three values measure three different intervals (not one interval at three fidelities) — each ends at requester readiness but subtracts from a different start point:

• dpc — measured inside the DPC log as relay_readiness − httpCallStartTime of the wake/create call. Baseline is the HTTP call start (after the container is up), so it is the tightest interval. Highest fidelity.
• kube_container_start — Kube fallback: requester ready − container state.running.startedAt. Matches the controller's own actuation-metric baseline; a coarser upper bound than dpc (starts earlier).
• kube_pod_create — Kube fallback reverted to requester ready − pod creationTimestamp because container-start was unavailable. Earliest baseline, coarsest, degraded.

A kube_pod_create reversion emits a logger.warning naming the requester (fired only for the final source, after DPC refinement, so a DPC-timed iteration never emits a spurious warning). Because the sources measure different intervals, per-iteration timing_source exists so consumers don't mix them blindly. It propagates through native_to_br0_1.py and renders as a three-way Source column in the analysis output; dpc_timing_available is retained as a derived property for backward-compatible readers.

Testing

• Unit: tests/test_dpc_log_parser.py (15) + tests/test_fma_functions.py (18); full suite 562 passed, 31 skipped.
• Preserves the large-file streaming and partial-log regressions from feat: Tighter FMA timing via DPC log parsing #1504 (adapted to the new format; the streaming regression uses a non-indicator filler so the first indicator genuinely lands past 256KB).
• Smoke test against a real controller log (1.12 MB, from a Qwen3-8B run): the updated parser extracts 11 records with sub-second hot-start t_hot (0.536 / 0.537 / 0.542 / 0.591 s, median 0.539s) — the same log yielded zero records under the old parser. Corroborates the ~0.51s vLLM-log weight-reload figure.

Draft status

Marked draft pending cluster end-to-end validation: confirm the emitted result.yaml shows timing_source: dpc with sub-second t_wake, and that any fallback iteration reports the correct source. The smoke test above exercised the DPC-log path against real data; the container-start fallback path is unit-tested only, and is what the cluster run will exercise. Will flip to ready for review once that passes.

[aavarghese]

Should this time also start at container_start instead of create?

[rubambiza]

Cluster e2e validation — passed ✅

Ran standup → 10 iterations → teardown on FMA v0.6.0 with Qwen3-8B, harness built from this branch tip (f5fbc11). Same FMA version / model / cluster as the earlier baseline run, which under the old parser produced dpc_timing_available: false on every iteration.

Emitted result.yaml:

• timing_source: dpc on all 10 iterations (derived dpc_timing_available: true consistent).
• Sub-second hot-start t_wake: 0.537, 0.537, 0.557, 0.587, 0.593, 0.597 s — the wake fidelity this change recovers, corroborating the ~0.51s vLLM-log weight-reload figure.
• Warm t_instance_create (DPC-internal HTTP timing): ~40.5s cluster + one 60.5s — far tighter than the Kube-timestamp upper bounds.
• No 403/forbidden/iterations: []; run + teardown clean, GPUs freed.

Scope note (honest coverage boundary)

Because every real actuation had DPC-log HTTP timing present, the run exercised only the dpc path. The Kube-timestamp fallback (timing_source: kube_container_start / kube_pod_create) did not fire on this healthy run — it triggers only when DPC-log timing is absent — so that path remains covered by unit tests (tests/test_fma_functions.py) rather than this live run.

Flipping to ready for review.