[Feature]: Decision Flow — visualize the routing pipeline in the dashboard

## What we are building

A new read-only dashboard page, **Routing → Decision Flow** (`/routing/flow`), that shows a merchant how their payments actually move through the Decision Engine: what runs first, what runs next, what never runs at all, and how the pieces they configured compose.

New users land on the dashboard with five strategies to configure and no picture of how they interact (one activation slot shared by rules / volume splits / experiments; success-rate, elimination, cost and commitments layered on top; debit and preferred-gateway driven by the request). This page is that picture.

## How it works

**Your routing stack** — a status board read live from the same endpoints Routing Hub already uses (`/routing/list/active`, `/rule/get successRate|elimination`, `/merchant-account/…/features`, the debit-routing flag). The active strategy shows its real saved name; off layers link to their configure pages; derived warnings surface config traps (empty slot, experiment holding the slot with the real-payments flag off, SR without elimination).

**The journey of one payment** — the stages of the decide-gateway pipeline in true execution order, grouped into Entry / Experiment layer / Network branch / Candidates / Ordering / Decision & learning. Only the stages that actually run for this merchant are drawn; a stage joins the flow the moment its configuration lands. Clicking a stage expands a live, configuration-aware description — including the merchant's actual rules (names, condition summaries, destinations), split percentages, and a minimal example request (required fields only) rebuilt from the live config.

**Connector lanes** — every connector the active strategy references is drawn as a continuous SVG ribbon flowing behind the stage cards: fanning out from the payment dot, lane thickness following volume-split shares, converging on the configured first choice when the strategy fully determines one. With nothing configured, a clearly-labeled example set (razorpay / payu / stripe) keeps the diagram meaningful.

**Honest by construction**
- No simulation, no writes: what-if payments stay on the Decision Simulator. This page only mirrors saved configuration.
- Anything payment-dependent (rule matching, eligibility outcomes, SR ordering) is described, never faked.
- With nothing configured, the Decision stage says plainly that the payment goes to the integration's `/decide-gateway` fallback list, and that the pick within it is effectively arbitrary.
- Fetch failures render as "couldn't load part of your configuration", not as false "Not set" facts.

## Follow-ups

- Replay a real payment's `/analytics/payment-audit` trace onto the same lanes.
- Optional backend niceties: an aggregate `GET /routing/stack/{merchant_id}`, and a read endpoint for the `merchant_config` PaymentFlow gates (`SrBasedRouting` / `EliminationBasedRouting`), which no API exposes today.

## Evidences

## Implementation

PR: https://github.com/juspay/decision-engine/pull/426
Parent tracker: https://github.com/juspay/hyperswitch-cloud/issues/23293