Two tests that could only pass on macOS

Two tests that could only pass on macOS Sharding the suite got it far enough to run, and the first Linux execution of these files found two assertions that were encoding this laptop's behaviour as the rule. Both are the tests being wrong; neither production path changes. **A seven-day window that measured six.** `orders::approve` computes `expires_at = decided_at + make_interval(days => 7)` in SQL, against the value Postgres stored — and `timestamptz` holds microseconds. The test passed a `Utc::now()` carrying nanoseconds, so the round trip lost the sub-microsecond remainder and the difference came back a few hundred nanoseconds short of seven days. `num_days` truncates, so the assertion read 6. It cannot fail on macOS, whose `Utc::now()` is microsecond-granular in practice, which is why it never has. The test now truncates to the resolution the column actually has. **A scan asserted to always have something to report.** `ulimit -f` is set in 512-byte blocks, so a 64KiB cap becomes 128 — exactly 65536 bytes under dash, and 131072 under bash, whose blocks are 1024 and which is `/bin/sh` on macOS. So on Linux the write stops precisely at the cap and `Sandbox::oversized` correctly finds nothing over it, while on macOS it overshoots and the scan is what catches it. The old assertion required the scan to be non-empty, which is macOS's slack written down as an invariant. The property that actually matters is that a runaway write is bounded *and* accounted for by whichever mechanism applies: over the cap must be caught, within it must not be reported. Asserting the equivalence covers both platforms and would still catch the thing this test exists for — an unbounded file nothing notices.