## Problem When a `.test` URL is hit and the requested service is not yet running, the loading page shows a spinner and redirects when that specific service reaches `up`. With service dependency ordering (#16), the requested service may sit queued for a while as its dependencies start in topological order. The user sees an opaque spinner with no signal that progress is being made. ## Proposal The loading page should subscribe to the requested service's full dependency closure and render progress as each dependency transitions through `starting` and `up`. The user sees concrete forward motion: "vite: up", "queue: up", "rails: starting", instead of a single indefinite spinner. ## Open questions - Visualization: progress bar (N of M up), per-service status list, or both? - What does "progress" mean when several dependencies start in parallel? - How is an upstream `crashed` rendered — the same as the current "app crashed" page, or inline on the loading page identifying which dep failed? ## Scope Depends on #16 landing first (the dep closure has to exist before the loading page can subscribe to it). Out of scope: changing the per-service status broadcasts themselves — those already exist and are sufficient for this UI.