Progress and Performance Tracking

[GALHP]

Summary

Adds per-table timing/telemetry and live nested progress bars to cloning:run —
feedback during long clones and visibility into where time goes (select vs.
transform vs. insert) on large databases.

Stacked PR — base: feat/development-setup · 2nd of 6 · Part of #164.
No code dependency on #165 (stacked only).

Motivation

Long clones ran with no output — no way to tell progress or where time went.
This adds (1) diagnostics: per-phase, per-table timings to find bottlenecks
(what surfaced the OFFSET problem fixed in #166), and (2) user feedback: live
progress.

What's changed

• Timing model (app/Data/Cloning/): TableRunPhase enum (one-shot
  CountingRows/DisableFkChecks/Clear; per-chunk Select/Transform/
  Insert; Loop wall-clock, each with a label); StatsTableTransferData +
  StatsLoopData/StatsLoopSnapshotData/StatsPhaseAggregateData accumulate
  per-phase wall-clock and row/throughput; a new in-progress TableRunStatus
  case.
• CloningRunOrchestrator — instruments the transfer loop, emitting
  per-table phase/timing via the existing onProgress callback (result contract
  unchanged).
• RunCommand — nested progress bars by verbosity on an interactive TTY:
  -v compact, -vv per-phase throughput, -vvv per-table timing summary, plus
  a per-table ETA. Non-TTY/CI output unchanged (bars suppressed).

Telemetry is opt-in via verbosity; the DTOs are plain readonly and unit-tested
in isolation.

Testing

Stats-model units (StatsTableTransferDataTest, TableRunPhaseTest),
orchestrator progress/timing (CloningRunOrchestratorTest), and RunCommandTest
for the rendered progress/summary output.