refactor(stats): retain exact finite timing samples

`SampleMode::Exact` retained exact samples for eight of the eleven public
timing metrics. Send call, timer error, and server processing always built
their `TimeMetric` with retention disabled, so a finite run reported no
median for them even though they are the same public `TimeStats` type and
appear in the same summary table with a Median column.

Derive one `retain_exact` decision from the sample mode in `CoreStats::new`
and apply it to every timing metric, so exact mode means the same thing for
all of them. Running-only mode is unchanged and still retains none of them.

The retention estimator counted eight exact sample streams per measurable
reply. Rename it to the eleven exact samples an ordinary successful probe
can retain and document the wider optional-measurement upper bound, which
raises the finite estimate on this target from 668 to 764 bytes per probe.
A test counts the metrics a fully measured probe actually retains and
compares it against that constant, so retention and its estimate cannot
drift apart unnoticed.

No new median-capability type was needed: `TimeStats::median_ns` already
distinguishes a retained median from an absent one, and an optional
measurement the server never supplied still produces no samples at all.

crates/irtt-stats/src/time_stats.rs

@@ -16,6 +16,9 @@ pub struct TimeStats {
     /// Arithmetic mean, in nanoseconds.
     pub mean_ns: f64,
     /// Median, in nanoseconds, when exact samples were retained.
+    ///
+    /// This is `None` when the collector was not configured to retain exact
+    /// samples, and also when it was but this metric received none.
     pub median_ns: Option<f64>,
     /// Sample variance, in nanoseconds squared.
     pub variance_ns2: f64,