test_in_tail: fix flaky throttling test by widening the lower time bound

[Watson1978]

Which issue(s) this PR fixes:
Fixes #

What this PR does / why we need it:

The test "lines collected with throttling" still fails intermittently even after #5381, especially on CI runners:

4) Failure: test: lines collected with throttling(TailInputTest::throttling logs at in_tail level):
  elapsed_seconds 1.8289766999998847 is out of allowed range:
    lower: 1.88 [sec]
    upper: 3.3200000000000003 [sec].

The throttling only guarantees that consecutive read starts (start_reading_time) are at least rate_period apart:

S_{N+1} - S_N >= rate_period   # always holds

However, the test measures the interval between emit events. An emit happens after a whole batch (limit lines, ~8MB here) has been read, i.e. at read_start + read_duration:

emit_N       ~= S_N + Tread_N
measured gap  = (S_{N+1} - S_N) + (Tread_{N+1} - Tread_N)
             ~= rate_period + (Tread_{N+1} - Tread_N)

So when an earlier batch is read more slowly than the next one — which is common for the first batch right after the file is opened — the measured emit interval dips below rate_period. The observing thread's 0.1s polling jitter adds to this. The reported failures (~0.17s below 2.0s) are fully explained by this read-time skew plus polling jitter.

The previous lower bound only accounted for the polling interval (sleep_interval * safety_ratio = 0.12), which was too tight and asymmetric with the upper bound (which already includes the watcher tick). This PR uses a symmetric jitter that also tolerates the read/observation latency, so the allowed range becomes [0.68, 3.32] sec.

This is a test-only measurement issue, not a product bug. The strict per-cycle line-count assertion (assert_equal(limit, d.record_count - prev_count)) is kept intact, so a regression that actually breaks throttling (emits back to back, gap ~0s) is still detected.

Docs Changes:
N/A

Release Note:
N/A