test: finish the isolated testing style sweep

[hughgrigg]

Finishes the sweep started in #16. The remaining six files are done, so all
thirteen now follow the isolated-testing-style skill.

The pull-count exception, kept

interval-stream.test.ts counts how far a source was consumed, which reads like
the call-count assertion the skill argues against. It stays, because laziness is
behaviour and consumption is the only way to observe it from outside. Each one
now says so:

it("stops early rather than draining an infinite source", () => {
  // Given a recurrence with no end, and a window three days wide. The meter
  // counts how far the source is consumed, which is the only way to observe
  // laziness from outside.
  const meter = metered(dailyForever("2026-03-01", "09:00", "17:00"));
  const window = span("2026-03-01T00:00", "2026-03-04T00:00");

  // When the whole clipped stream is drained.
  const clipped = [...clip(meter.stream, window)];

  // Then three days come back, and the source gave up four: the three
  // results, plus the one that proved the window was behind it.
  assertArrayLength(clipped, 3);
  assertIdentical(meter.pulled(), 4);
});

One test removed

query.test.ts held two tests with byte-identical bodies under different names.
Both advanced 24 hours from midnight on 2026-03-29 over an always rule and
asserted 01:00 the next morning:

it("takes the exact equivalent happily", () => { /* … */ });
it("measures exact time, so a clock change does not lose an hour", () => {
  const reached = advanceBy(when("2026-03-29T00:00"), hours(24), {
    during: { type: "always" },
  });
  assertIdentical(reached?.toPlainDateTime().toString(), "2026-03-30T01:00:00");
});

They are one test now, keeping the better explanation. The count goes from 200 to
199 for that reason alone, and it is the only test the sweep removes.

The rest

Same pattern as #16. Given/when/then filled in with the case, module-level
fixtures moved inside a root describe, and faker for values the assertions do
not turn on. The parse messages read as documentation of the boundary, so each
case says which mistake it stands for:

it("refuses a misspelled field rather than quietly dropping it", () => {
  // Given a zone with a typo in the field name. This is the dangerous one:
  // dropping it would parse as a valid rule with no zone, read in whatever
  // zone the query used, and nothing would have said so.
  // When it is parsed.
  // Then it is refused, with the fields the type does take.
  assertIdentical(
    complaintAbout({
      type: "timeOfDay",
      from: "09:00",
      to: "17:00",
      zonee: "Europe/London",
    }),
    "rule.zonee: is not a field of a timeOfDay rule. Expected from, to, zone",
  );
});

Four lint findings came up and were fixed by naming intermediates rather than by
turning rules off: three max-nested-calls and one prefer-structured-clone on
a JSON.parse(JSON.stringify(…)) round trip, which is now two named steps.

Checks

pnpm check passes, and passed at each commit.

      Tests  199 passed (199)
Statements   : 99.49% ( 394/396 )
Branches     : 97.22% ( 245/252 )

Behaviour is untouched apart from the duplicate above. No new dependencies here:
faker arrived in #16.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 37 minutes

Limit details: You’ve used all 2 included reviews currently available under your plan. You completed 83 included PR reviews in the past 7 days; at that activity level, included reviews refill at 2 reviews per hour.

This review is too large to run within your organization's remaining usage spending cap. Raise or remove your spending cap in the billing tab, then retry.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: b290a55c-ca8c-4ab0-a7e8-c815b4c17e9d

📥 Commits

Reviewing files that changed from the base of the PR and between 9b563cf and 684d99d.

📒 Files selected for processing (6)

• src/build.test.ts
• src/interpret.test.ts
• src/interval-stream.test.ts
• src/parse.test.ts
• src/query.test.ts
• src/resolve.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}