Feature/waterfall view phase1

[DevSars24]

Waterfall/Timeline View — Phase 1

What

Adds a simple, server-rendered horizontal bar (waterfall) view showing outgoing
HTTP dependency calls positioned and sized proportionally within the parent
request's total duration. This replaces the "flat list only" view with an
at-a-glance visual of which calls ran sequentially/in parallel and which is
the bottleneck.

Why

Today, DebugProbe shows outgoing calls as a flat list (e.g. "Restaurant API
→ 800ms"). This tells you how long each call took, but not when it started
relative to the others, or where time is being lost. A waterfall makes the
bottleneck visible in one glance.

Scope

Phase 1 = simple CSS bars only. No JavaScript, no tooltips, no zoom, no
new dependencies — matches the existing architecture where every dashboard
element (BuildTraceCard, BuildOutgoingRequestCard, etc.) is server-rendered
HTML styled with CSS. Interactive features are intentionally deferred to a
future proposal, pending review of this simpler version.

Files changed

• HtmlRenderer.cs — added BuildWaterfallSection(DebugEntry entry), wired
  into RenderDetailsPage above the existing outgoing-request cards (which
  are unchanged).
• debugprobe.css — added .waterfall-container, .waterfall-row,
  .wf-label, .wf-track, .wf-bar, .wf-bar--error, plus a mobile clamp.

No changes to DebugProbeMiddleware.cs, DebugProbeHttpClientHandler.cs,
DebugEntryStore.cs, or any data-capture code — all required timing data
was already being captured, this is a display-layer-only change.

How it works

• Computes left% and width% for each outgoing call relative to the
  parent request's total duration, clamped to 0–100% to avoid edge-case
  rendering bugs.
• Uses InvariantCulture for percentage formatting to guarantee dot-decimal
  CSS values regardless of server locale.
• Reuses the existing label redaction/display logic (GetDisplayTarget())
  — no new redaction path introduced.
• Failed calls get a .wf-bar--error modifier (red), matching the existing
  status-color convention elsewhere in the dashboard.
• Empty OutgoingRequests → no waterfall section rendered (guard clause).

Testing

• dotnet test: 61/61 passing, no regressions.
• Manual verification: triggered /Demo/ExecuteExternalRequests (2 sequential
  outgoing calls), confirmed via /debug/{id}:
  • 2 .waterfall-row elements rendered
  • Bar percentages valid, dot-decimal, correctly clamped
  • Waterfall section renders above the existing outgoing-request cards
  • Labels match existing redaction output
  • No exceptions during rendering

Follow-up polish included in this PR

• Simplified the null-check on the guard clause to match existing convention
  in the file (the collection is never null by contract).
• Extracted 0.0/100.0 clamp bounds into named constants, matching the
  const pattern already used in RenderIndexPage.
• Fixed a minor duration-text inconsistency ({ms}ms → {ms} ms) to match
  formatting used everywhere else on the details page.
• Did not add an XML doc comment to the new method, since no other
  private method in HtmlRenderer.cs has one — adding one only here would
  be inconsistent with the file's convention.

[georgidhristov]

Tested this locally and everything works as expected.

The waterfall view renders correctly above the existing outgoing request cards, the bars are positioned properly, and the current server-rendered approach fits well with the existing dashboard architecture.

Good phase 1 implementation. Approved and merged.