fix(cli): --speed banana silently replayed unpaced, which is the wrong measurement

[DanielWLiu07]

Found by taking a defect out of the sibling repo and asking whether this one has it.

Voxel's parser used std::atoi on five count flags, so a typo parsed to zero and silently disabled the feature. This repo's parser is better — parse_int uses from_chars and requires the whole string consumed, flag_value returns nullopt on malformed input, and callers check it. So the answer was mostly no.

flag_double was the exception

It returned the fallback on unparseable input and on a flag given with no value at all:

basis replay capture.feedlog --speed banana
basis replay capture.feedlog --speed

Both fell back to 0.0 — which means "replay flat out". No error, no warning, a normal-looking report.

Why it's worse here than in voxel

--speed 1 exists to replay at the venue's real arrival schedule and measure response time instead of service time. docs/bench/latency.md's entire finding is that the service p99 understates what a consumer waits by 13.3x.

So a typo returned exactly the service-time numbers that mode was built to correct — in the benchmark built to correct them. The only tell was the absence of one line in the output.

Fix

flag_double now returns std::optional<double> like flag_value, signalling rather than substituting. Both call sites reject with a message naming the flag and the expected shape. The missing-value case is handled explicitly rather than falling out of the loop bound, since that's how it went unnoticed.

--speed banana      -> exit 1
--speed 1x          -> exit 1  (trailing junk)
--speed             -> exit 1  (no value)
--speed -1          -> exit 1  (negative)
--pace-spin-ms xyz  -> exit 1

--speed 0 and --speed 1 unchanged. 228 tests, perf gate, and bench-input check all pass.